www.elsolucionario.net 


Quinta edición 


noenierta del Software 


Un enfoque práctico 


E 


li Rm 4 


! E E : a DU AA 
da Y Lee pal HEN A 


$ PON Cds 
S «MA: 


y 
1 


EN para . 7 
A 


f A uu? 7 DN 
1, pa 
" El po 


A 


HOTER S. AS 


DAPIADO POR. Dasgel AWNCE 


A AA 


www.elsolucionario.net 


WWW el solucionario. nel 


SÉ subscribe RSS ES Find on Facebook E Pollows rn Teeets 


Encuentra en nuestra página los Textos Universitarios que necesitas! 


Libros y Solucionarios en formato digital 
El complemento ¡deal para estar preparados para los exámenes! 


Los Solucionarios contienen TODOS los problemas del libro resueltos 
y explicados paso a paso de forma clara.. 


Visitanos para descargarlos GRATIS! 
Descargas directas mucho más fáciles... 


WWW ELSOLUCIONARIO NET 


Biology Investigación Operativa Computer 5cience 
Matemáticas Awanzadas 
Physics Estadistica Chemistry Geometría 
Math 


: Electrónica Circuitos PES 
modinámis Cálculo 


e ; E Economía Análisis Numérico 
Civil Engineering j 
. . Ecuaciones Diferenciales 
Electrical Engineering Álgebra 
Electromagnetismo 


www.elsolucionario.net 


CONSULTOR EDITORIAL 
AREA DE INFORMÁTICA Y COMPUTACION 


Gerardo Quiroz Vieyra 

Ingeniero de Comunicacionesy Electrónica 

por la ESIME del Instituto Politécnico Nacional 
Profesor de la Universidad Autónoma Metropolitana 
Unidad Xochimilco 

MÉXICO 


www.elsolucionario.net 


INGENIERÍA DEL SOFTWARE 
UN ENFOQUE PRÁCTICO 


Quinta edición 


Roger S. Pressman 


R.S. Pressman é Associates, Inc. 


ADAPTACIÓN 


Darrel Ince 
Open University 


TRADUCCIÓN 


Rafael Ojeda Martín Isabel Morales Jareño 
Virgilio Yagile Galaup Salvador Sánchez Alonso 


Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 
Facultad de Informática / Escuela Universitaria de Informática 
Universidad Pontificia de Salamanca campus Madrid (España) 


Jorge A. Torres Jiménez 
Director de la carrera de Ingeniería de Sistemas Computacionales 
Instituto Tecnológico (TEC) de Monterrey campus Querétaro (México) 


COLABORACIÓN 


Oscar San Juan Martínez Juana González González 
Ricardo Lozano Quesada Lorena Esmoris Galán 


Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 
Facultad de Informática / Escuela Universitaria de Informática 
Universidad Pontificia de Salamanca campus Madrid (España) 


REVISIÓN TÉCNICA 


Héctor Castán Rodríguez 
Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 
Facultad de Informática / Escuela Universitaria de Informática 
Universidad Pontificia de Salamanca campus Madrid (España) 


DIRECCIÓN, COORDINACIÓN Y REVISIÓN TÉCNICA 


Luis Joyanes Aguilar 
Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software 
Facultad de Informática / Escuela Universitaria de Informática 
Universidad Pontificia de Salamanca campus Madrid (España) 


E 


MADRID + BUENOS AIRES - CARACAS - GUATEMALA + LISBOA - MÉXICO 
NUEVA YORK - PANAMÁ - SANJUAN + SANTAFÉ DEBOGOTÁ - SANTIAGO - SÁO PAULO 
AUCKLAND + HAMBURGO + LONDRES» MILÁN + MONTREAL + NUEVADELHI - PARÍS 
SAN FRANCISCO: SIDNEY + SINGAPUR + ST. LOUIS « TOKIO - TORONTO 


www.elsolucionario.net 


INGENIERÍA DEL SOFTWARE. Un enfoque práctico.(5.' edición) 


No está permitida la reproducción total o parcial de este libro, ni su tratamiento infor- 
mático, ni la transmisión de ninguna forma o por cualquier medio, ya sea electrónico, 
mecánico, por fotocopia, por registro u otros métodos, sin el permiso previo y por 
escrito de los titulares del Copyright. 


DERECHOS RESERVADOS 0 2002, respecto a la quinta edición en español, por 
McGRAW-HILL/INTERAMERICANA DE ESPAÑA, S. A. U. 
Edificio Valrealty, 1.” planta 
Basauri, 17 
28023 Aravaca (Madrid) 


Traducido de la quinta edición en inglés de 
SOFTWARE ENGINEERING.A Practitioner”s Approach. European Adaptation 


ISBN: 0-07-709677-0 


Copyright O MMI, by The McGraw-Hill Companies 


ISBN: 84-481-3214-9 
Depósito legal: M. 42.852-2001 


Editora: Concepción Femández Madrid 
Diseño de cubierta: Design Master Dima 
Compuesto en FER 

Impreso en: Imprenta FARESO. $, A. 


IMPRESO EN ESPAÑA - PRINTED IN SPAIN 


www.elsolucionario.net 


CONTENIDOS A PRIMERA VISTA 


ACERCA DEL AUTOR, XXI 

PREFACIO, XXV 

PRÓLOGO A LA CUARTA EDICIÓN EN ESPAÑOL, XXIX 
PRÓLOGO ALA QUINTA EDICIÓN EN ESPAÑOL, XXXII 
UTILIZACIÓN DEL LIBRO, XXXVII 


PARTE PRIMERA: EL PRODUCTO Y ELPROCESO 
CAPÍTULO 1. ELPRODUCTO, 3 
CAPÍTULO 2.  ELPROCESO, 13 


PARTE SEGUNDA: GESTIÓN DE PROYECTOS DE SOFTWARE 


CAPÍTULO 3.  CONCEPTOSSOBRE GESTIÓN DE PROYECTOS, 37 

CAPÍTULO 4. PROCESO DE SOFTWAREY MÉTRICAS DE PROYECTOS, 53 
CAPITULO 5.  PLANIFICACIÓNDE PROYECTOSDE SOFTWARE, 77 

CAPITULO 6. ANÁLISIS Y GESTIÓN DEL RIESGO, 97 

CAPITULO 7.  PLANIFICACIÓNTEMPORAL Y SEGUIMIENTO DEL PROYECTO, 111 
CAPITULO 8. GARANTIA DE CALIDAD DEL SOFTWARE(8QA/GCS), 131 
CAPITULO 9.  GESTIÓNDE LA CONFIGURACIÓN DEL SOFTWARE(GCSISCM), 151 


PARTE TERCERA: MÉTODOS CONVENCIONALES PARA LA INGENIERÍA DEL SOFTWARE 
CAPÍTULO 10. 
CAPITULO 11. 
CAPÍTULO 12. 
CAPÍTULO 13. 
CAPITULO 14. 
CAPITULO15. 
CAPÍTULO 16. 
CAPÍTULO 17. 
CAPITULO18. 
CAPÍTULO 19. 


PARTE CUARTA: INGENIERIA DEL SOFTWARE ORIENTADA A OBJETOS 


INGENIERIA DE SISTEMAS, 165 
CONCEPTOS Y PRINCIPIOS DEL ANALISIS, 181 
MODELADO DEL ANÁLISIS, 199 

CONCEPTOS Y PRINCIPIOS DE DISENO, 219 
DISENO ARQUITECTÓNICO, 237 

DISENO DE LA INTERFAZ DE USUARIO, 259 
DISEÑO A NIVELDE COMPONENTES, 273 
TÉCNICAS DE PRUEBA DEL SOFTWARE, 281 
ESTRATEGIAS DE PRUEBA DEL SOFTWARE, 305 
MÉTRICAS TÉCNICAS DEL SOFTWARE, 323 


CAPITULO 20. CONCEPTOS Y PRINCIPIOS ORIENTADOSA OBJETOS, 343 

CAPITULO 21. ANÁLISIS ORIENTADOA OBJETOS, 361 

CAPITULO 22. DISENO ORIENTADOA OBJETOS, 379 

CAPITULO23. PRUEBAS ORIENTADAS A OBJETOS, 407 

CAPITULO24. MÉTRICAS TÉCNICAS PARA SISTEMAS ORIENTADOSA OBJETOS, 421 


PARTE OUINTA: TEMAS AVANZADOS EN INGENIERÍA DEL SOFTWARE 


CAPITULO25. MÉTODOS FORMALES, 435 

CAPÍTULO 26. INGENIERIA DEL SOFTWAREDE SALA LIMPIA, 459 

CAPÍTULO 27. INGENIERIA DEL SOFTWAREBASADA EN COMPONENTES, 473 

CAPÍTULO 28, INGENIERÍA DEL SOFTWAREDEL COMERCIO ELECTRÓNICO 
CLIENTEISERVIDOR, 491 

CAPÍTULO 29. INGENIERÍA WEB, 521 


v 


CONTENIDOS A PRIMERA VISta 


CAPÍTULO 30. 
CAPITULO 31. 
CAPÍTULO 32. 


APÉNDICE, 581 
ÍNDICE, 589 


www.elsolucionario.net 


REINGENIERIA, 541 
INGENIERÍA DEL SOFTWAREASISTIDA POR COMPUTADORA, 559 
PERSPECTIVAS FUTURAS, 573 


www.elsolucionario.net 


CONTENIDO 


ACERCA DEL AUTOR, XXI! 

PREFACIO, XXV 

PRÓLOGO A LA CUARTA EDICIÓN EN ESPAÑOL, XXIX 
PRÓLOGO A LA QUINTA EDICIÓN EN ESPAÑOL, XXXIII 
UTILIZACIÓN DEL LIBRO, XXXVII 


PARTE PRIMERA: EL PRODUCTO Y ELPROCESO 


CAPÍTULO 1: ELPRODUCTO, 3 


1,1, 
1.2. 


1.3. 
1.4. 


LA EVOLUCIÓN DEL SOFTWARE4 

EL SOFTWARE, 5 

1.2.1, CARACTERÍSTICAS DEL SOFTWARE, 5 

1.2.2. APLICACIONES DEL SOFTWARE, 6 

SOFTWARE: ¿UNA CRISIS EN EL HORIZONTE?, 8 
MITOS DEL SOFTWARE, 8 


RESUMEN, 10 

REFERENCIAS, 10 

PROBLEMAS Y PUNTOS A CONSIDERAR, 11 

OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 11 


CAPÍTULO 2: ELPROCESO, 13 


2.1. 


2.2. 
2.3. 
2.4. 
2.5, 
2.6. 
2.7. 


2.8. 
2.9. 
2.10. 
2.11. 
2.12. 


INGENIERÍA DEL SOFTWARE: UNA TECNOLOGÍA ESTRATIFICADA, 14 
2.1.1. PROCESO, MÉTODOS Y HERRAMIENTAS, 14 

2.1.2. UNA VISIÓN GENERAL DE LA INGENIERÍA DEL SOFTWARE, 14 
EL PROCESO DEL SOFTWARE, 16 

MODELOS DE PROCESO DEL SOFTWARE, 19 

EL MODELO LINEAL SECUENCIAL, 20 

EL MODELO DE CONSTRUCCIÓN DE PROTOTIPOS, 21 

EL MODELO DRA, 22 

MODELOS EVOLUTIVOS DE PROCESO DEL SOFTWARE, 23 
2.7.1. EL MODELO INCREMENTAL, 23 

2.7.2. ELMODELO ESPIRAL, 24 

2.7.3. ELMODELO ESPIRAL WINWIN (Victoria$; Victoria), 26 

2.7.4. EL MODELO DE DESARROLLO CONCURRENTE, 27 
DESARROLLO BASADO EN COMPONENTES, 28 

EL MODELO DE MÉTODOS FORMALES, 29 

TÉCNICAS DE CUARTA GENERACIÓN, 29 

TECNOLOGÍAS DE PROCESO, 30 

PRODUCTO Y PROCESO, 31 


RESUMEN, 31 

REFERENCIAS, 32 

PROBLEMAS Y PUNTOS A CONSIDERAR, 32 

OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 33 


PARTE SE 


4 


DA: DE PROYECTOS DE SOFTWARE 


CAPÍTULO 3: CONCEPTOS SOBRE GESTIÓN DE PROYECTOS, 37 


3.1. 


EL ESPECTRO DE LA GESTIÓN, 38 
3.1.1. PERSONAL, 38 


vI 


CONTENIDO 


3.2. 


3.3, 


3.4, 


3.5, 
3.6. 
3.7. 


www.elsolucionario.net 


3.12. PRODUCTO, 38 
3.1.3, PROCESO, 38 

3.1.4. PROYECTO, 39 

PERSONAL, 39 

3.2.1. LOS PARTICIPANTES, 39 

3.2.2. LOS JEFES DE EQUIPO, 40 

3.2.3. ELEQUIPO DE SOFTWARE, 40 

3.2.4. ASPECTOS SOBRE LA COORDINACIÓN Y LA COMUNICACIÓN, 43 
PRODUCTO, 44 

3.3.1. ÁMBITO DEL SOFTWARE, 44 

3.3.2. DESCOMPOSICIÓN DEL PROBLEMA, 45 

PROCESO, 45 

3.4.1, MADURACIÓN DEL PRODUCTO Y DEL PROCESO, 46 

3.42, DESCOMPOSICIÓN DEL PROCESO, 47 

PROYECTO, 48 

EL PRINCIPIO WW3HH, 49 

PRÁCTICAS CRÍTICAS, 49 


RESUMEN, 50 

REFERENCIAS, 50 

PROBLEMAS Y PUNTOS A CONSIDERAR, 51 

OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 51 


CAPÍTULO 4: PROCESO DE SOFTWARE Y MÉTRICAS DE PROYECTOS, 53 


4.1. 
4.2, 


4.3, 


4.4, 
4.5. 


4.6. 


4.7. 


4,8. 


4.9, 
4.10. 


MEDIDAS, MÉTRICAS E INDICADORES, 54 

MÉTRICAS EN EL PROCESO Y DOMINIOS DEL PROYECTO, 55 

4.2.1. MÉTRICAS DEL PROCESO Y MEJORAS EN EL PROCESO DEL SOFTWARE, 55 
4,22, MÉTRICAS DEL PROYECTO, 58 

MEDICIONES DEL SOFTWARE, 58 

4.3.1. MÉTRICAS ORIENTADASALTAMAÑO, 59 

4.3.2. MÉTRICAS ORIENTADAS A LA FUNCIÓN, 61 

4.33. MÉTRICAS AMPLIADAS DE PUNTO DE FUNCIÓN, 61 

RECONCILIACIÓN DE LOS DIFERENTES ENFOQUES DE MÉTRICAS, 62 
MÉTRICAS PARA LA CALIDAD DEL SOFTWARE, 63 

4.5.1. VISIÓN GENERAL DE LOS FACTORES QUE AFECTAN A LA CALIDAD, 63 
4.5.2, MEDIDA DELA CALIDAD, 64 

4.5.3. EFICACIA DE LA ELIMINACIÓN DE DEFECTOS, 64 

INTEGRACIÓN DE LAS MÉTRICAS DENTRO DEL PROCESO DE INGENIERÍA 
DEL SOFTWARE, 65 

4.6.1. ARGUMENTOS PARA LAS MÉTRICAS DEL SOFTWARE, 65 

4.6.2. ESTABLECIMIENTODE UNA LÍNEA BASE, 66 

4.6.3, COLECCIÓN DE MÉTRICAS, CÓMPUTO Y EVALUACIÓN, 66 

EL DESARROLLO DE LA MÉTRICA Y DELA OPM (OBJETIVO, PREGUNTA, 
MÉTRICA), 67 

VARIACIÓN DE LA GESTIÓN: CONTROL DE PROCESOS ESTADÍSTICOS, 69 
MÉTRICA PARA ORGANIZACIONES PEQUEÑAS, 71 

ESTABLECIMIENTO DE UN PROGRAMA DE MÉTRICAS DE SOFTWARE, 72 


RESUMEN, 73 

REFERENCIAS, 74 

PROBLEMAS Y PUNTOS A CONSIDERAR, 75 

OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 75 


CAPÍTULO 5; PLANIFICACIÓN DE PROYECTOS DE SOFTWARE, 77 


5.1, 
5,2, 


OBSERVACIONES SOBRE LA ESTIMACIÓN, 78 
OBJETIVOS DE LA PLANIFICACIÓN DEL PROYECTO, 79 


VII 


5.3, 


5.4. 


5.5, 


5.6. 


5.7. 


5.8. 


5.9, 


www.elsolucionario.net 


CONTENIDO 


ÁMBITO DEL SOFTWARE, 79 

5.3.1. OBTENCIÓN DE LA INFORMACIÓN NECESARIA PARA EL ÁMBITO, 79 
5.32. VIABILIDAD, 80 

5,33, UN EJEMPLO DE ÁMBITO, 80 

RECURSOS, 82 

5.4.1. RECURSOS HUMANOS, 82 

5.42. RECURSOS DE SOFTWAREREUTILIZABLES, 82 

5.4.3. RECURSOS DE ENTORNO, 83 

ESTIMACIÓN DELPROYECTO DE SOFTWARE, $4 
TÉCNICAS DE DESCOMPOSICIÓN, 85 

5.6.1 TAMAÑO DEL SOFTWARE, 85 

5.6.2, ESTIMACIÓN BASADA EN EL PROBLEMA, 86 

5.6.3. UNEJEMPLO DE ESTIMACIÓN BASADA ENLDC, 87 

5.6.4. UN EJEMPLO DEESTIMACIÓN BASADA EN PF, 88 

5.6.5, ESTIMACIÓN BASADA EN EL PROCESO, 89 

5.6.6. UN EJEMPLO DE ESTIMACIÓN BASADA EN EL PROCESO, 89 
MODELOS EMPÍRICOS DE ESTIMACIÓN, 90 

5.7.1. LAESTRUCTURA DE LOS MODELOS DE ESTIMACIÓN, 90 
5.72. EL MODELO COCOMO, 91 

5.7.3. LA ECUACIÓN DEL SOFTWARE, 92 

LADECISIÓN DEDESARROLLAR-COMPRAR, 92 

5.8.1. CREACIÓN DE UN ÁRBOL DE DECISIONES, 93 

5.8.2, SUBCONTRATACIÓN (OUTSOURCING), 94 
HERRAMIENTAS AUTOMÁTICAS DE ESTIMACIÓN, 94 


RESUMEN, 95 

REFERENCIAS, 95 

PROBLEMAS Y PUNTOS A CONSIDERAR, 96 

OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 96 


CAPÍTULO 6: ANÁLISIS Y GESTIÓN DEL RIESGO, 97 


6.1. 
6.2. 
6.3. 


6.4, 


6.5. 
6.6. 
6.7. 
6.8. 


ESTRATEGIAS DERIESGO PROACTIVAS VS. REACTIVAS, 98 
RIESGO DEL SOFTWARE, 98 

IDENTIFICACIÓN DEL RIESGO, 99 

6.3.1. EVALUACIÓN GLOBAL DEL RIESGO DEL PROYECTO, 100 
6.3.2. COMPONENTES Y CONTROLADORES DEL RIESGO, 101 
PROYECCIÓN DELRIESGO, 101 

6.4.1. DESARROLLO DE UNA TABLA DE RIESGO, 101 

6.4.2, EVALUACIÓN DEL IMPACTO DEL RIESGO, 103 

6.4.3. EVALUACIÓN DEL RIESGO, 103 

REFINAMIENTO DEL RIESGO, 104 

REDUCCIÓN, SUPERVISIÓN Y GESTIÓN DELRIESGO, 105 
RIESGOS Y PELIGROS PARA LA SEGURIDAD, 106 
ELPLANRSGR, 107 


RESUMEN, 107 

REFERENCIAS, 107 

PROBLEMAS Y PUNTOS A CONSIDERAR, 108 

OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 108 


CAPÍTULO 7: PLANIFICACIÓN TEMPORAL Y SEGUIMIENTO DEL PROYECTO, 111 


7.1. 


CONCEPTOS BÁSICOS, 112 
7.1.1, COMENTARIOS SOBRE<LOS RETRASOS», 112 
7.1.2. PRINCIPIO BÁSICOS, 113 


IX 


CONTENIDO 


7.2, 


7.3. 


7.4. 
7.5, 
1.6. 
7.7, 


7.8. 
7.9. 
7.10. 


www.elsolucionario.net 


LA RELACIÓN ENTRE LAS PERSONAS Y ELESFUERZO, 114 

7.2.1. UN EJEMPLO, 115 

7.2.2, UNA RELACIÓN EMPÍRICA, 115 

7.2.3. DISTRIBUCIÓN DEL ESFUERZO, 115 

DEFINICIÓN DE UN CONJUNTO DE TAREAS PARA EL PROYECTO DE SOFTWARE, 116 
7.3.1. GRADO DERIGOR, 117 

7.3.2. DEFINIR LOS CRITERIOS DE ADAPTACIÓN, 117 

7.3.3, CÁLCULO DEL VALOR SELECTOR DEL CONJUNTO DE TAREAS, 117 

7.3.4, INTERPRETAR EL VALOR SCT Y SELECCIONAR EL CONJUNTO DE TAREAS, 119 
SELECCIÓN DE LAS TAREAS DE INGENIERÍA DEL SOFTWARE, 119 
REFINAMIENTO DE LAS TAREAS PRINCIPALES, 120 

DEFINIR UNA RED DE TAREAS, 121 

LA PLANIFICACIÓN TEMPORAL, 122 

7.7.1. GRÁFICOS DE TIEMPO, 123 

7.7.2,  SEGUIMIENTODE LA PLANIFICACIÓN TEMPORAL, 124 

ANÁLISIS DE VALOR GANADO, 125 

SEGUIMIENTO DEL ERROR, 126 

EL PLAN DEL PROYECTO, 127 


RESUMEN, 127 

REFERENCIAS, 128 

PROBLEMAS Y PUNTOS A CONSIDERAR, 128 

OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 129 


CAPÍTULO 8: GARANTÍA DE CALIDAD DEL SOFTWARE(S04/GCS), 131 
8.1. CONCEPTOS DE CALIDAD, 132 


8.2, 
8.3. 


8.4, 


8.5. 


8.6. 
8.7. 


8.8. 
8.9, 
8.10. 


8.1.1. CALIDAD, 132 

8,12. CONTROLDE CALIDAD, 133 

8.1.3, GARANTÍA DE CALIDAD, 133 

8.14 COSTE DE CALIDAD, 133 

LA TENDENCIA DE LA CALIDAD, 134 

GARANTIA DE CALIDAD DEL SOFTWARE, 135 

8.3.1. PROBLEMAS DE FONDO, 135 

8,32, ACTIVIDADES DE SQA, 136 

REVISIONES DEL SOFTWARE, 137 

8.4.1. IMPACTO DE LOS DEFECTOS DEL SOFTWARESOBRE EL COSTE, 137 
8.4.2, AMPLIFICACIÓN Y ELIMINACIÓN DE DEFECTOS, 138 
REVISIONES TÉCNICAS FORMALES, 138 

8.5.1. LA REUNIÓN DE REVISIÓN, 139 

8.5.2, REGISTRO E INFORME DE LA REVISIÓN, 140 

8.5.3. DIRECTRICES PARA LA REVISIÓN, 140 

GARANTÍA DE CALIDADESTADÍSTICA, 141 
FIABILIDAD DEL SOFTWARE, 143 

8.7.1. MEDIDAS DE FIABILIDAD Y DE DISPONIBILIDAD, 143 
8,72, SEGURIDAD DEL SOFTWARE, 144 

PRUEBA DE ERRORES PARA EL SOFTWARE, 145 

EL ESTÁNDAR DE CALIDADISO 9001,146 

EL PLAN DE SQA, 147 


RESUMEN, 148 

REFERENCIAS, 148 

PROBLEMAS Y PUNTOS A CONSIDERAR, 149 

OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 150 


CAPÍTULO 9: GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE(GCS/SCM), 151 


9.1. 


GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE, 152 
XxX 


www.elsolucionario.net 


CONTENIDO 


9.1.1. LÍNEAS BASE, 152 
9.1.2. ELEMENTOS DE CONFIGURACIÓN DEL SOFTWARE, 153 
9.2, ELPROCESO DEGGCS, 154 
9,3. IDENTIFICACIÓN DE OBJETOS EN LA CONFIGURACIÓN DEL SOFTWARE, 154 
9.4. CONTROL DE VERSIONES, 155 
9.5. CONTROL DE CAMBIOS, 156 
9.6. AUDITORÍA DELA CONFIGURACIÓN, 158 
9.7. INFORMES DE ESTADO, 159 
RESUMEN, 159 
REFERENCIAS, 160 
PROBLEMAS Y PUNTOS A CONSIDERAR, 160 
OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 161 


PARTE TERCERA: METODOS CONVENCIONALES PARA LA INGENIERÍA DEL SOFTWARE 


CAPÍTULO 10: INGENIERÍA DE SISTEMAS, 165 
10.1. SISTEMAS BASADOS EN COMPUTADORA, 167 
10.2. LA JERARQUÍA DE LA INGENIERÍA DE SISTEMAS, 167 
10.2,1. MODELADO DEL SISTEMA, 167 
102.2, SIMULACIÓN DEL SISTEMA, 168 
10.3. INGENIERIA DE PROCESO DE NEGOCIO: UNA VISIÓN GENERAL, 169 
10.4. INGENIERIA DE PRODUCTO: UNA VISIÓN GENERAL, 171 
10,5, INGENIERÍA DE REQUISITOS, 171 
10.5.1. IDENTIFICACIÓN DE REQUISITOS, 172 
10.5.2. ANÁLISIS Y NEGOCIACIÓN DE REQUISITOS, 173 
10.5.3. ESPECIFICACIÓN DE REQUISITOS, 173 
10.5.4. MODELADO DEL SISTEMA, 174 
10.5.5. VALIDACIÓN DE REQUISITOS, 174 
10.5.6, GESTIÓN DE REQUISITOS, 174 
10.6. MODELADO DEL SISTEMA, 175 
RESUMEN, 178 
REFERENCIAS, 178 
PROBLEMAS Y PUNTOS A CONSIDERAR, 179 
OTRAS LECTURAS Y FUENTES DE INFORMACION, 179 


CAPITULO 11; CONCEPTOS Y PRINCIPIOS DEL ANÁLISIS, 181 
11.1. ANÁLISIS DE REQUISITOS, 182 
11.2. IDENTIFICACIÓN DE REQUISITOS PARA EL SOFTWARE, 183 
112.1. INICIO DELPROCESO, 183 
11,22, TÉCNICAS PARA FACILITAR LAS ESPECIFICACIONES DE UNA APLICACIÓN, 184 
11.23. DESPLIEGUE DE LA FUNCIÓN DE CALIDAD, 186 
11.24. CASOS DE USO, 186 
11,3, PRINCIPIOS DEL ANÁLISIS, 188 
113.1. EL DOMINIO DE LA INFORMACIÓN, 189 
11.32. MODELADO, 190 
11,3,3, PARTICIÓN, 190 
11.34. VISIONES ESENCIALES Y DE IMPLEMENTACIÓN, 191 
11.4. CREACIÓN DE PROTOTIPOS DEL SOFTWARE, 192 
11.4.1. SELECCIÓN DEL ENFOQUE DE CREACIÓN DE PROTOTIPOS, 192 
11.42. MÉTODOS Y HERRAMIENTASPARA EL DESARROLLO DE PROTOTIPOS, 193 
11.5. ESPECIFICACIÓN, 193 


XI 


www.elsolucionario.net 


CONTENIDO 


11.5,1, PRINCIPIOS DE LA ESPECIFICACIÓN, 194 
11,5,2, REPRESENTACIÓN, 194 
11.53, LAESPECIFICACIÓN DE LOS REQUISITOS DEL SOFTWARE, 194 
11.6. REVISIÓN DELA ESPECIFICACIÓN, 195 
RESUMEN, 196 
REFERENCIAS, 196 
PROBLEMAS Y PUNTOS A CONSIDERAR, 197 
OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 197 


CAPÍTULO 12: MODELADO DEL ANÁLISIS, 199 

12.1. BREVE HISTORIA, 200 

12.2. LOS ELEMENTOS DEL MODELO DE ANÁLISIS, 200 

12.3. MODELADO DE DATOS, 201 
12.3.1. OBJETOS DE DATOS, ATRIBUTOS Y RELACIONES, 201 
12.3.2, CARDINALIDAD Y MODALIDAD, 203 
12.3.3. DIAGRAMAS ENTIDAD-RELACIÓN ,204 

12.4. MODELADO FUNCIONAL Y FLUJO DE INFORMACIÓN, 205 
12.4.1. DIAGRAMAS DE FLUJO DE DATOS, 206 
12.42. AMPLIACIONES PARA SISTEMAS DE TIEMPO REAL, 207 
12,4,3, AMPLIACIONES DE WARD Y MELLOR, 207 
12.4.4. AMPLIACIONES DE HATLEY Y PIRBHATI, 208 

12.5. MODELADO DEL COMPORTAMIENTO, 209 

12.6. MECANISMOS DELANÁLISIS ESTRUCTURADO, 210 
12.6.1. CREACIÓN DE UN DIAGRAMA ENTIDAD-RELACIÓN, 210 
12.62. CREACIÓN DE UN MODELO DE FLUJO DE DATOS, 211 
12.6.3. CREACIÓN DE UN MODELO DE FLUJO DE CONTROL, 213 
12.6.4. LAESPECIFICACIÓN DE CONTROL, 214 
12.6.5. LA ESPECIFICACIÓN DEL PROCESO, 214 

12.7. EL DICCIONARIO DE DATOS, 215 

12.8. OTROS MÉTODOS CLÁSICOS DE ANÁLISIS, 216 

RESUMEN, 216 

REFERENCIAS, 217 

PROBLEMAS Y PUNTOS A CONSIDERAR, 217 

OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 218 


CAPÍTULO 13; CONCEPTOS Y PRINCIPIOS DE DISEÑO, 219 
13.1. DISENO DEL SOFTWAREE INGENIERIA DEL SOFTWARE, 220 
13.2. ELPROCESO DE DISEÑO, 221 

13.2.1. DISEÑO Y CALIDAD DEL SOFTWARE, 221 

132,2, LAEVOLUCIÓN DEL DISEÑO DEL SOFTWARE, 221 
13.3. PRINCIPIOS DEL DISEÑO, 222 
13.4. CONCEPTOS DEL DISEÑO, 223 

13.4.1. ABSTRACCIÓN, 223 

13.42. REFINAMIENTO, 224 

13.43. MODULARIDAD, 224 

13,4,4, ARQUITECTURA DEL SOFTWARE, 226 

134.5. JERARQUÍA DE CONTROL, 226 

13.46. DIVISIÓN ESTRUCTURAL, 227 

134,7, ESTRUCTURA DE DATOS, 228 

13.4.8. PROCEDIMIENTO DE SOFTWARE, 229 

13.4,9, OCULTACIÓN DE INFORMACIÓN, 229 
13.5. DISEÑO MODULAR EFECTIVO. 229 


xi 


www.elsolucionario.net 


CONTENIDO 


13.5.1. INDEPENDENCIA FUNCIONAL, 229 
13.52. COHESIÓN, 230 
13.5,3, ACOPLAMIENTO, 231 
13.6. HEURÍSTICA DE DISEÑO PARA UNA MODULARIDADEFECTIVA, 231 
13.7. ELMODELO DEL DISEÑO, 233 
13.8. DOCUMENTACIÓN DEL DISEÑO, 233 
RESUMEN, 234 
REFERENCIAS, 234 
PROBLEMAS Y PUNTOS A CONSIDERAR, 235 
OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 236 


CAPÍTULO 14: DISEÑO ARQUITECTÓNICO, 237 
14.1. ARQUITECTURA DEL SOFTWARE, 238 
14.11. ¿QUÉ ES ARQUITECTURA?, 238 
14,1.2. ¿POR QUÉ ES IMPORTANTE LA ARQUITECTURA?, 238 
14.2. DISEÑO DE DATOS, 239 


14.2.1. MODELADO DE DATOS, ESTRUCTURAS DE DATOS, BASES DE DATOS Y ALMACÉN DE 
DATOS, 239 


14.2.2. DISENO DE DATOS A NIVEL DE COMPONENTES, 240 
14,3, ESTILOSARQUITECTÓNICOS, 241 
14.31, UNA BREVETAXONOMÍA DE ESTILOS Y PATRONES, 241 
14.32. ORGANIZACIÓN Y REFINAMIENTO, 243 
14.4, ANÁLISIS DE DISEÑOS ARQUITECTÓNICOS ALTERNATIVOS, 243 
14.4.1. UN MÉTODO DEANÁLISIS DE COMPROMISO PARA LA ARQUITECTURA, 243 
14.42. GUÍA CUANTITATIVAPARA EL DISEÑO ARQUITECTÓNICO, 244 
144,3. COMPLEJIDAD ARQUITECTÓNICA, 245 
14.5. CONVERSIÓN DE LOS REQUISITOS EN UNA ARQUITECTURA DEL SOFTWARE, 245 
14.5.1, FLUJO DETRANSFORMACIÓN, 246 
14.5,2, FLUJO DE TRANSACCIÓN, 246 
14.6. ANÁLISIS DE LAS TRANSFORMACIONES, 247 
14.6.1. UN EJEMPLO, 247 
14.62. PASOS DEL DISENO, 247 
14.7. ANÁLISIS DE LAS TRANSACCIONES, 252 
14.7.1. UN EJEMPLO, 252 
14.7.2, PASOS DEL DISEÑO, 252 
14.8. REFINAMIENTO DEL DISEÑO ARQUITECTÓNICO, 255 
RESUMEN, 256 
REFERENCIAS, 256 
PROBLEMAS Y PUNTOS A CONSIDERAR, 257 
OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 258 


CAPÍTULO 15; DISEÑO DE LA INTERFAZ DE USUARIO, 259 
15.1. LAS REGLAS DE ORO, 260 
15.1.1. DAR ELCONTROLALUSUARIO, 260 
15.1.2. REDUCIR LA CARGA DE MEMORIA DEL USUARIO, 260 
15,1,3, CONSTRUCCIÓN DE UNA INTERFAZ. CONSISTENTE, 261 
15.2. DISEÑO DE LA INTERFAZ DE USUARIO, 262 
15.2.1. MODELOS DE DISEÑO DE LAINTERFAZ, 262 
15.2.2. EL PROCESO DE DISEÑO DE LA INTERFAZDE USUARIO, 263 
15.3. ANÁLISIS Y MODELADO DE TAREAS, 264 
15.4. ACTIVIDADES DEL DISENO DE LA INTERFAZ, 264 
15.4.1, DEFINICIÓN DE OBJETOS Y ACCIONES DE LA INTERFAZ, 265 
15.42. PROBLEMAS DEL DISEÑO, 266 


Xnl 


www.elsolucionario.net 


CONTENIDO 


15,5, HERRAMIENTAS DE IMPLEMENTACIÓN, 268 
15.6. EVALUACIÓN DEL DISENO, 268 

RESUMEN, 270 

REFERENCIAS, 270 

PROBLEMAS Y PUNTOS A CONSIDERAR, 270 

OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 271 


CAPÍTULO 16: DISEÑO A NIVEL DE COMPONENTES, 273 
16.1, PROGRAMACIÓN ESTRUCTURADA, 274 
16.1.1. NOTACIÓN GRÁFICA DEL DISEÑO, 274 
16.1.2, NOTACIÓN TABULAR DE DISEÑO, 274 
16.1.3. LENGUAJE DE DISENO DE PROGRAMAS, 276 
16.1,4, UN EJEMPLO DE LDP, 277 
16.2. COMPARACIÓN DE NOTACIONES DE DISEÑO, 278 
RESUMEN, 279 
REFERENCIAS, 279 
PROBLEMAS Y PUNTOS A CONSIDERAR, 280 
OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 280 


CAPÍTULO 17: TÉCNICAS DE PRUEBA DEL SOFTWARE, 281 

17.1. FUNDAMENTOS DE LAS PRUEBAS DEL SOFTWARE, 282 
17.1.1. OBJETIVOS DELAS PRUEBAS, 282 
17.1.2. PRINCIPIOS DE LAS PRUEBAS, 282 
17.13. FACILIDAD DE PRUEBA, 283 

17.2. DISEÑO DE CASOS DE PRUEBA, 285 

17.3. PRUEBA DE CAJA BLANCA, 286 

17.4. PRUEBA DEL CAMINO BÁSICO, 286 
17.4.1. NOTACIÓN DE GRAFO DE FLUJO, 286 
17.42. COMPLEJIDAD CICLOMÁTICA, 287 
17.43. OBTENCIÓN DE CASOS DE PRUEBA, 288 
17.4,4, MATRICES DE GRAFOS, 290 

17.5. PRUEBADE LA ESTRUCTURA DE CONTROL, 291 
17.5.1. PRUEBA DE CONDICIÓN, 291 
17.52, PRUEBA DEL FLUJO DE DATOS, 292 
17.53. PRUEBA DE BUCLES, 293 

17.6. PRUEBA DE CAJA NEGRA, 294 
17.6.1. MÉTODOS DE PRUEBA BASADOS EN GRAFOS, 294 
17.62. PARTICIÓN EQUIVALENTE, 296 
17.6,3, ANÁLISIS DE VALORES LÍMITE, 297 
17.64. PRUEBADE COMPARACIÓN, 297 
17.6.5. PRUEBA DE LA TABLA ORTOGONAL, 298 

17.7. PRUEBA DE ENTORNOS ESPECIALIZADOS, ARQUITECTURAS Y APLICACIONES, 299 
17.71. PRUEBA DE INTERFACES GRÁFICAS DE USUARIO (IGUs), 299 
17.72. PRUEBA DE ARQUITECTURA CLIENTE/SERVIDOR, 300 
17.7.3, PRUEBA DE LA DOCUMENTACIÓN Y FACILIDADES DE AYUDA, 300 
17.7.4. PRUEBA DE SISTEMAS DE TIEMPO-REAL, 300 

RESUMEN, 301 

REFERENCIAS, 302 

PROBLEMAS Y PUNTOS A CONSIDERAR, 302 

OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 303 


XIV 


www.elsolucionario.net 


CAPITULO 18: ESTRATEGIAS DE PRUEBA DEL SOFTWARE, 305 


18.1. 


18.2. 
18.3. 


18,4, 


18.5. 


18.6. 


18.7. 


UN ENFOQUE ESTRATÉGICO PARA LAS PRUEBAS DEL SOFTWARE, 306 
18.1.1. VERIFICACIÓN Y VALIDACIÓN, 306 

18.1.2. ORGANIZACIÓN PARA LAS PRUEBAS DEL SOFTWARE, 307 
18.1.3. UNA ESTRATEGIADE PRUEBA DEL SOFTWARE, 307 

18.1.4. CRITERIOS PARACOMPLETARLA PRUEBA, 308 
ASPECTOS ESTRATÉGICOS, 309 

PRUEBA DE UNIDAD, 310 

18.3.1. CONSIDERACIONES SOBRE LA PRUEBA DE UNIDAD, 310 
18.3.2, PROCEDIMIENTOS DE PRUEBA DE UNIDAD, 311 

PRUEBA DE INTEGRACIÓN, 312 

18.4.1. INTEGRACIÓN DESCENDENTE, 312 

18.42. INTEGRACIÓN ASCENDENTE, 313 

13,4,3, PRUEBA DE REGRESIÓN, 314 

18,4,4, PRUEBA DE HUMO, 314 

18.4.5. COMENTARIOS SOBRELA PRUEBA DE INTEGRACIÓN, 315 
PRUEBA DE VALIDACIÓN, 316 

18.5,1, CRITERIOS DE LA PRUEBA DE VALIDACIÓN, 316 

18.52, REVISIÓN DELA CONFIGURACIÓN, 316 

18.5.3. PRUEBAS ALFAY BETA, 316 

PRUEBA DEL SISTEMA, 317 

18.6.1. PRUEBA DE RECUPERACIÓN, 317 

18.6.2. PRUEBA DE SEGURIDAD, 317 

18.63. PRUEBA DE RESISTENCIA (STRESS), 318 

18.6.4. PRUEBA DE RENDIMIENTO, 318 

EL ARTE DE LA DEPURACIÓN, 318 

18.7.1, ELPROCESO DE DEPURACIÓN, 319 

18,7.2, CONSIDERACIONES PSICOLÓGICAS, 319 

18.7.3. ENFOQUES DE LA DEPURACIÓN, 320 


RESUMEN, 321 

REFERENCIAS, 321 

PROBLEMAS Y PUNTOS A CONSIDERAR, 322 

OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 322 


CAPÍTULO 19: MÉTRICAS TÉCNICAS DEL SOFTWARE, 323 


19.1. 


19.2, 


19.3. 


19.4, 


19.5, 


CALIDAD DEL SOFTWARE, 324 

19.1.1. FACTORES DE CALIDAD DE McALL, 324 

19.1.2. FURPS, 325 

19.1,3. FACTORES DE CALIDAD 180 9126,326 

19.1.4. LATRANSICIÓN A UNA VISIÓN CUANTITATIVA, 326 


UNA ESTRUCTURA PARA LAS MÉTRICAS TÉCNICAS DEL SOFTWARE, 327 


19,2.1. ELRETO DELAS MÉTRICAS TÉCNICAS, 327 
19.2,2, PRINCIPIOS DE MEDICIÓN, 328 


CONTENIDO 


19,2,3, CARACTERÍSTICAS FUNDAMENTALES DE LAS MÉTRICAS DEL SOFTWARE, 328 


MÉTRICAS DEL MODELO DE ANÁLISIS, 329 

19.3.1. MÉTRICAS BASADAS EN LAFUNCIÓN, 329 

19,3,2, LA MÉTRICA BANG, 330 

19.3.3. MÉTRICAS DE LA CALIDAD DE LA ESPECIFICACIÓN, 331 
MÉTRICAS DEL MODELO DE DISENO, 332 

19,4,1. MÉTRICAS DEL DISEÑO ARQUITECTÓNICO, 332 

19.4.2. MÉTRICAS DE DISEÑO A NIVEL DE COMPONENTES, 333 
19.43. MÉTRICAS DE DISEÑO DE INTERFAZ, 335 

MÉTRICAS DEL CÓDIGO FUENTE, 336 


xv 


www.elsolucionario.net 


CONTENIDO 


19.6, MÉTRICAS PARA PRUEBAS, 337 

19.7. MÉTRICAS DEL MANTENIMIENTO, 338 
RESUMEN, 338 

REFERENCIAS, 338 

PROBLEMAS Y PUNTOS A CONSIDERAR, 339 

OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 340 


PARTE CUARTA: INGENIERÍA DEL SOFTWAREORIENTADAA OBIETOS 
CAPÍTULO 20: CONCEPTOS Y PRINCIPIOS ORIENTADOS A OBJETOS, 343 
20.1. EL PARADIGMA ORIENTADO A OBJETOS, 344 
20.2. CONCEPTOS DE ORIENTACIÓN A OBJETOS, 345 
202.1, CLASES Y OBJETOS, 346 
202.2. ATRIBUTOS, 347 
202.3. OPERACIONES, MÉTODOS Y SERVICIOS, 347 
20,2.4. MENSAJES, 347 
20.2.5. ENCAPSULAMIENTO, HERENCIA Y POLIMORFISMO, 348 
20.3. IDENTIFICACIÓN DE LOS ELEMENTOS DE UN MODELO DE OBJETOS, 350 
20.3.1. IDENTIFICACIÓN DE CLASES Y OBJETOS, 350 
20,32, ESPECIFICACIÓN DE ATRIBUTOS, 353 
20.33. DEFINICIÓN DE OPERACIONES, 353 
20.3.4. FIN DE LA DEFINICIÓN DEL OBJETO, 354 
20.4. GESTIÓN DE PROYECTOS DE SOFTWARE ORIENTADO A OBJETOS, 354 
20.4.1. EL MARCO DE PROCESO COMÚN PARA 00,355 
20,4,2, MÉTRICAS Y ESTIMACIÓN EN PROYECTOS ORIENTADOSA OBJETOS, 356 
20,4,3, UN ENFOQUE OO PARA ESTIMACIONES Y PLANIFICACIÓN, 357 
20.44. SEGUIMIENTO DEL PROGRESO EN UN PROYECTO ORIENTADO A OBJETOS, 358 
RESUMEN, 358 
REFERENCIAS, 359 
PROBLEMAS Y PUNTOS A CONSIDERAR, 359 
OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 360 


CAPITULO 21: ANÁLISIS ORIENTADO A OBJETOS, 361 
21.1. ANÁLISIS ORIENTADOA OBJETOS, 362 
20.1.1, ENFOQUES CONVENCIONALES Y ENFOQUES 00,362 
21.12, ELPANORAMA DELAOO, 362 
21.1.3. UN ENFOQUE UNIFICADO PARA EL AOO, 363 
21.2. ANÁLISIS DEL DOMINIO, 364 
212.1. ANÁLISIS DE REUTILIZACIÓN Y DEL DOMINIO, 364 
21.2.2. ELPROCESO DEANÁLISIS DEL DOMINIO, 365 
21.3. COMPONENTES GENÉRICOS DEL MODELO DE ANÁLISIS 00, 366 
21.4. ELPROCESO DE AOO, 367 
214.1. CASOS DE USO, 367 
21,42, MODELADO DE CLASES-RESPONSABILIDADES-COLABORACIONES, 368 
21.4,3. DEFINICIÓN DE ESTRUCTURAS Y JERARQUÍAS, 371 
21,4,4, DEFINICIÓN DE SUBSISTEMAS, 372 
21.5. EL MODELO OBJETO-RELACIÓN, 373 
21.6. ELMODELO OBJETO-COMPORTAMIENTO, 374 
21.6.1. IDENTIFICACIÓN DE SUCESOS CON CASOS DE USO, 374 
21.6.2. REPRESENTACIONES DE ESTADOS, 375 
RESUMEN, 376 
REFERENCIAS, 377 


XVI 


www.elsolucionario.net 


CONTENIDO 


PROBLEMAS Y PUNTOSA CONSIDERAR, 377 
OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 378 


CAPÍTULO 22: DISEÑO ORIENTADO A OBIETOS,379 
22.1. DISEÑO PARA SISTEMAS ORIENTADOSA OBJETOS, 380 
22.1.1. ENFOQUE CONVENCIONAL VS. 00,380 
22.1.2. ASPECTOS DEL DISENO, 381 
22.1.3, ELPANORAMA DE DOO, 382 
22.1.4. UN ENFOQUE UNIFICADO PARA EL DOO, 383 
22.2. ELPROCESO DE DISEÑO DE SISTEMA, 384 
222.1, PARTICIONAR EL MODELO DE ANÁLISIS, 384 
22.2.2. ASIGNACIÓN DE CONCURRENCIA Y SUBSISTEMAS, 385 
22.23. COMPONENTE DE ADMINISTRACIÓN DE TAREAS, 386 
22.2,4. COMPONENTE DE INTERFAZ DE USUARIO, 386 
22.2.5. COMPONENTEDE LA ADMINISTRACIÓN DE DATOS, 386 
22.2.6. COMPONENTE DE GESTIÓN DE RECURSOS, 387 
22.2.7. COMUNICACIONES ENTRE SUBSISTEMAS, 387 
22.3. PROCESO DE DISEÑO DE OBJETOS, 388 
22.3.1. DESCRIPCIÓN DE OBJETOS, 388 
22.32. DISEÑO DE ALGORITMOS Y ESTRUCTURAS DE DATOS, 389 
22.4. PATRONES DE DISENO, 390 
224.1. ¿QUÉ ES UN PATRÓN DE DISENO?, 390 
22.4.2. OTRO EJEMPLO DE UN PATRÓN, 391 
22.43. UN EJEMPLO FINAL DE UN PATRÓN, 391 
22,4,4, DESCRIPCIÓN DE UN PATRÓN DE DISENO, 392 
22,4,5, EL FUTURO DE LOS PATRONES, 392 
22.5, PROGRAMACIÓN ORIENTADA A OBJETOS, 393 
22.5.1. ELMODELO DE CLASES, 393 
22.52, GENERALIZACIÓN, 394 
22.5.3. AGREGACIÓN Y COMPOSICIÓN, 394 
23.54, ASOCIACIONES, 395 
22.5.5. CASOS DE USO, 395 
22.5.6. COLABORACIONES, 396 
22.5.7. DIAGRAMAS DEESTADO, 397 
22.6. CASO DE ESTUDIO. LIBROS EN LÍNEA, 398 
22.6.1, LIBROS-EN-LÍNEA, 399 
22,7. PROGRAMACIÓN ORIENTADA A OBJETOS, 400 
RESUMEN, 404 
REFERENCIAS, 404 
PROBLEMAS Y PUNTOSA CONSIDERAR, 405 
OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 405 


CAPÍTULO 23: PRUEBAS ORIENTADAS A OBIETOS, 407 

23.1. AMPLIANDO LA VISIÓN DE LAS PRUEBAS, 408 

23.2. PRUEBAS DE LOS MODELOS DE AOO Y DOO, 409 
232.1. EXACTITUD DE LOS MODELOS DEAOO Y DOO, 409 
232.2. CONSISTENCIA DE LOS MODELOS DEAOO Y DOO, 409 

23.3. ESTRATEGIASDE PRUEBAS ORIENTADASA OBJETOS, 410 
233.1, LAS PRUEBAS DE UNIDAD EN EL CONTEXTO DELA 00, 410 
233.2, LAS PRUEBAS DE INTEGRACIÓN EN EL CONTEXTO OO, 411 
23,33, PRUEBAS DE VALIDACIÓN EN UN CONTEXTO 00,411 

23.4. DISEÑO DE CASOS DE PRUEBA PARA SOFTWARE00,412 
234.1. IMPLICACIONES DE LOS CONCEPTOS DE 00 AL DISEÑO DE CASOS DE PRUEBA, 412 


XVII 


CONTENIDO 


23.5, 


23.6. 


www.elsolucionario.net 


23.42. APLICABILIDAD DE LOS MÉTODOS CONVENCIONALES DE DISEÑO DE CASOS DE 
PRUEBA, 412 

23.4.3, PRUEBAS BASADAS EN ERRORES, 412 

23.4.4, ELIMPACTO DE LA PROGRAMACIÓN 00 EN LAS PRUEBAS, 413 

23.4.5. CASOS DE PRUEBA Y JERARQUÍA DE CLASES, 414 

23.4.6. DISENO DE PRUEBAS BASADAS EN EL ESCENARIO, 414 

23.4,7, LAS ESTRUCTURAS DE PRUEBAS SUPERFICIALES Y PROFUNDAS, 415 

MÉTODOS DE PRUEBA APLICABLES AL NIVEL DE CLASES, 416 

23.5.1. LA VERIFICACIÓNAL AZAR PARA CLASES 00,416 

23.52. PRUEBA DE PARTICIÓN AL NIVEL DE CLASES, 416 

DISEÑO DE CASOS DE PRUEBA INTERCLASES, 417 

23.6.1, PRUEBA DE MÚLTIPLESCLASES, 417 

23.62, PRUEBA DERIVADA DE LOS MODELOS DE COMPORTAMIENTO, 418 


RESUMEN, 419 

REFERENCIAS, 419 

PROBLEMAS Y PUNTOS A CONSIDERAR, 419 

OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 420 


CAPÍTULO 24: MÉTRICAS TÉCNICAS PARA SISTEMAS ORIENTADOS A OBJETOS, 421 


24.1. 
24.2, 


24.3. 
24,4. 


24.5, 


24.6. 


24.7. 


EL PROPÓSITO DE LAS MÉTRICAS ORIENTADAS A OBJETOS, 422 
CARACTERISTICAS DISTINTIVAS DE LAS MÉTRICAS ORIENTADASA OBJETOS, 422 
24.2.1. LOCALIZACIÓN, 422 

24,22, ENCAPSULACIÓN, 422 

242,3. OCULTACIÓN DE INFORMACIÓN, 423 

24,2,4, HERENCIA, 423 

24,2,5. ABSTRACCIÓN, 423 

MÉTRICAS PARA EL MODELO DE DISEÑO 00,423 

MÉTRICAS ORIENTADASA CLASES, 424 

244.1. LA SERIE DE MÉTRICAS CK, 425 

24.4.2. MÉTRICAS PROPUESTAS POR LORENZ Y KIDD, 426 

24.4.3. LA COLECCIÓN DE MÉTRICAS MDOO, 427 

MÉTRICAS ORIENTADASA OPERACIONES, 428 

MÉTRICAS PARA PRUEBAS ORIENTADAS A OBJETOS, 428 
MÉTRICAS PARA PROYECTOS ORIENTADOS A OBJETOS, 429 


RESUMEN, 430 

REFERENCIAS, 430 

PROBLEMAS Y PUNTOS A CONSIDERAR, 431 

OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 431 


PARTE OUINTA: TEMAS AVANZADOS EN INGENIERÍA DEL SOFTWARE 
CAPÍTULO 25; MÉTODOS FORMALES, 435 


25.1. 


25.2, 


CONCEPTOS BÁSICOS, 436 

25.1.1, DEFICIENCIAS DE LOS ENFOQUES MENOS FORMALES, 436 
25.1.2. MATEMÁTICAS EN EL DESARROLLO DEL SOFTWARE, 437 
25.1,3, CONCEPTOS DE LOS MÉTODOS FORMALES, 438 
PRELIMINARES MATEMÁTICOS, 441 

25.2,1. CONJUNTOS Y ESPECIFICACIÓN CONSTRUCTIVA, 442 
25,2,2, OPERADORES DE CONJUNTOS, 442 

25.23. OPERADORES LÓGICOS, 443 

25.2.4, SUCESIONES. 443 


XVIII 


25,3, 


25,4, 
25.5, 


25.6. 
25.7. 
25.8. 
25.9. 


25.10. 


www.elsolucionario.net 


CONTENIDO 


APLICACIÓN DELA NOTACIÓN MATEMÁTICA PARA LA ESPECIFICACIÓN 
FORMAL, 444 


LENGUAJES FORMALES DE ESPECIFICACIÓN, 445 


USO DELLENGUAJE Z PARA REPRESENTAR UN COMPONENTE EJEMPLO DE 
SOFTWARE, 446 


MÉTODOS FORMALES BASADOS EN OBJETOS, 447 
ESPECIFICACIÓN ALGEBRAICA, 450 

MÉTODOS FORMALES CONCURRENTES, 452 

LOS DIEZ MANDAMIENTOS DE LOS MÉTODOS FORMALES, 455 
MÉTODOS FORMALES: EL FUTURO, 456 


RESUMEN, 456 

REFERENCIAS, 457 

PROBLEMAS Y PUNTOS A CONSIDERAR, 457 

OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 458 


CAPITULO?26: 
26.1. 


26.2. 


26.3. 


26.4. 


INGENIERIA DEL SOFTWAREDE SALA LIMPIA, 459 
EL ENFOQUE DE SALA LIMPIA, 460 

26.1.1. LAESTRATEGIADE SALA LIMPIA, 460 

26.1.2. ¿QUÉ HACE DIFERENTE LA SALA LIMPIA?, 461 
ESPECIFICACIÓN FUNCIONAL, 462 

26.2.1. ESPECIFICACIÓN DE CAJA NEGRA, 463 

26.2.2. ESPECIFICACIÓN DE CAJA DE ESTADO, 463 

262.3. ESPECIFICACIÓN DE CAJA LIMPIA, 464 
REFINAMIENTOY VERIFICACIÓN DEL DISEÑO, 464 
26.3.1. REFINAMIENTO Y VERIFICACIÓN DEL DISEÑO, 464 
26,32. VENTAJAS DE LA VERIFICACIÓN DEL DISENO, 466 
PRUEBA DE SALA LIMPIA, 467 

264.1. PRUEBA ESTADÍSTICA DE CASOS PRÁCTICOS, 467 
26,4,2, CERTIFICACIÓN, 468 


RESUMEN, 469 

REFERENCIAS, 469 

PROBLEMAS Y PUNTOS A CONSIDERAR, 470 

OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 470 


CAPÍTULO 27: 
27.1, 
27.2. 
27.3. 


27.4. 


27,5, 


27.6. 


INGENIERIA DEL SOFTWAREBASADA EN COMPONENTES, 473 
INGENIERÍA DE SISTEMAS BASADA EN COMPONENTES, 474 

EL PROCESO DE ISBC, 475 

INGENIERIA DEL DOMINIO, 476 

273.1. EL PROCESO DE ANÁLISIS DEL DOMINIO, 476 

273.2. FUNCIONES DE CARACTERIZACIÓN, 477 

27.33. MODELADO ESTRUCTURAL Y PUNTOS DE ESTRUCTURA, 477 
DESARROLLO BASADO EN COMPONENTES, 478 

27.4.1. CUALIFICACIÓN, ADAPTACIÓN Y COMPOSICIÓN DE COMPONENTES, 479 
27.42. INGENIERÍA DE COMPONENTES, 481 

27.43. ANÁLISIS Y DISEÑO PARA LA REUTILIZACIÓN, 481 
CLASIFICACIÓN Y RECUPERACIÓN DE COMPONENTES, 482 

27.5.1, DESCRIPCIÓN DE COMPONENTES REUTILIZABLES, 482 

27.52. EL ENTORNO DE REUTILIZACIÓN, 484 

ECONOMIA DE LA ISBC, 484 

27.6.1, IMPACTO EN LA CALIDAD, PRODUCTIVIDAD Y COSTE, 484 

27.6.2. ANÁLISIS DE COSTE EMPLEANDO PUNTOS DE ESTRUCTURA, 485 


XIX 


CONTENIDO 


www.elsolucionario.net 


27.6.3. MÉTRICAS DE REUTILIZACIÓN, 486 


RESUMEN, 486 

REFERENCIAS, 487 

PROBLEMASY PUNTOS A CONSIDERAR, 488 

OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 488 


CAPITULO 28 


: INGENIERIA DEL SOFTWAREDEL COMERCIO ELECTRÓNICO 


CLIENTE/SERVIDOR, 491 


28.1. INTRODUCCIÓN, 492 
28.2. SISTEMAS DISTRIBUIDOS, 492 


28.2.1. CLIENTES Y SERVIDORES, 492 

28.2.2. CATEGORÍAS DE SERVIDORES, 492 

28.2.3. SOFIWARE INTERMEDIO (MIDDLEWARE), 494 
28.2.4.UN EJEMPLO DE SOFIWARE INTERMEDIO, 495 


28.3, ARQUITECTURAS ESTRATIFICADAS, 496 
28.4. PROTOCOLOS, 497 


28.5, 


28.6. 


28.7. 


28.8. 


28.4.1. EL CONCEPTO, 497 
28.4.2.IP EICMP, 498 
28.4,3. POP3, 498 
28.4.4.EL PROTOCOLO HTTP, 499 
UN SISTEMA DE COMERCIO ELECTRÓNICO, 499 
28.5.1.¿QUÉ ES EL COMERCIO ELECTRÓNICO?, 499 
28.5.2. UN SISTEMA TÍPICO DE COMERCIO ELECTRÓNICO, 500 
TECNOLOGIAS USADAS PARA EL COMERCIO ELECTRÓNICO, 502 
28.6.1. CONEXIONES (SOCKETS), 502 
28.6.2. OBJETOS DISTRIBUIDOS, 502 
28.6.3. ESPACIOS, 503 
28.6.4.CGI, 503 
28.6.5.CONTENIDO EJECUTABLE, 503 
28.6.6. PAQUETES CLIENTE/SERVIDOR, 504 
EL DISENO DE SISTEMAS DISTRIBUIDOS, 504 


28.7.1. CORRESPONDENCIA DEL VOLUMEN DE TRANSMISIÓN CON LOS MEDIOS DETRANS- 
MISIÓN, 504 


28.7.2. MANTENIMIENTO DE LOS DATOS MÁS USADOS EN UN ALMACENAMIENTO 
RÁPIDO, 504 


28.7.3. MANTENIMIENTO DE LOS DATOS CERCA DE DONDE SE UTILIZAN, 504 

28.74, UTILIZACIÓN DE LADUPLICACIÓN DE DATOS TODO LO POSIBLE, 505 

28.7.5. ELIMINAR CUELLOS DE BOTELLA, 505 

28.7.6. MINIMIZAR LA NECESIDAD DE UN GRAN CONOCIMIENTO DEL SISTEMA, 505 
28.7.7. AGRUPAR DATOS AFINES EN LA MISMA UBICACIÓN, 505 


28.7.8. CONSIDERAR LA UTILIZACIÓN DE SERVIDORES DEDICADOS A FUNCIONES 
FRECUENTES, 506 


28.7.9. CORRESPONDENCIA DE LA TECNOLOGÍA CON LAS EXIGENCIAS DE 
RENDIMIENTO, 506 


28.7.10. EMPLEO DEL PARALELISMOTODO LO POSIBLE, 506 
28.7.11. UTILIZACIÓN DE LA COMPRESIÓN DE DATOS TODO LO POSIBLE, 506 
28.7.12. DISEÑO PARA EL FALLO, 506 
28.7.13. MINIMIZAR LA LATENCIA, 506 
28.7.14.EPÍLOGO, 506 
INGENIERIA DE SEGURIDAD, 507 
28.8.1. ENCRIPTACIÓN, 507 
28.8.2. FUNCIONES DE COMPENDIO DE MENSAJES, 508 
28.8.3. FIRMAS DIGITALES, 508 
28.8.4. CERTIFICACIONES DIGITALES, 508 


XX 


www.elsolucionario.net 


CONTENIDO 


28.9. COMPONENTES DE SOFTWAREPARA SISTEMAS C/S, 509 
28.9.1, INTRODUCCIÓN, 509 
28.9,2. DISTRIBUCIÓN DE COMPONENTES DE SOFTWARE, 509 
28.9.3. LÍNEAS GENERALES PARALA DISTRIBUCIÓN DE COMPONENTES DE 
APLICACIONES, 510 
28.9.4. ENLAZADO DE COMPONENTES DE SOFTWARECSS, 511 
28.9.5, SOFTWAREINTERMEDIO (MIDDLEWARE) Y ARQUITECTURAS DE AGENTE DE SOLICI- 
TUD DE OBJETOS, 512 
28.10. INGENIERÍA DEL SOFTWAREPARA SISTEMAS C/S, 512 
28.11. PROBLEMAS DE MODELADO DE ANÁLISIS, 512 
28.12. DISENO DE SISTEMAS C/S, 513 
28.12,1. DISEÑO ARQUITECTÓNICO PARA SISTEMAS CLIENTE/SERVIDOR, 513 
28.12.2. ENFOQUES DE DISEÑO CONVENCIONALES PARA SOFTWAREDE APLICACIONES, 514 
28.12,3. DISEÑO DE BASES DE DATOS, 514 
28.12.4. VISIÓN GENERAL DE UN ENFOQUE DE DISEÑO, 515 
28.12.5, ITERACIÓN DEL DISEÑO DE PROCESOS, 516 
28.13. PROBLEMAS DE LAS PRUEBAS, 516 
28.13.1. ESTRATEGIAGENERAL DE PRUEBAS C/S, 516 
28.13.2. TÁCTICA DE PRUEBAS C/S, 518 
RESUMEN, 518 
REFERENCIAS, 519 
PROBLEMAS Y PUNTOS A CONSIDERAR, 519 
OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 519 


CAPITULO 29: INGENIERIA WEB, 521 
29.1. LOS ATRIBUTOS DE APLICACIONES BASADAS EN WEB, 522 
29.1.1. ATRIBUTOS DE CALIDAD, 523 
29.1.2. LAS TECNOLOGÍAS, 524 
29.2. ELPROCESO DE IWEB, 525 
29.3. UN MARCO DE TRABAJO PARA LA IWEB, 525 
29.4. FORMULACIÓN Y ANÁLISIS DE SISTEMAS BASADOS EN WEB, 526 
29.4.1. FORMULACIÓN, 526 
29.4.2. ANÁLISIS, 527 
29.5. DISEÑO PARA APLICACIONES BASADAS EN WEB, 527 
29.5.1. DISEÑO ARQUITECTÓNICO, 528 
29.5,2, DISEÑO DENAVEGACIÓN, 530 
29.5.3. DISEÑO DE LA INTERFAZ, 531 
29.6. PRUEBAS DE LAS APLICACIONES BASADAS EN WEB, 532 
29.7. PROBLEMAS DE GESTIÓN, 533 
29,7.1. EL EQUIPO DE IWEB, 533 
297.2, GESTIÓN DEL PROYECTO, 534 
29.1.3. PROBLEMAS GCS PARA LA IWEB, 536 
RESUMEN, 537 
REFERENCIAS, 538 
PROBLEMAS Y PUNTOS A CONSIDERAR, 539 
OTRAS LECTURAS Y FUENTES DE INFORMA CIÓN, 539 


CAPÍTULO 30 :REINGENIERIA, 541 
30.1. REINGENIERÍA DE PROCESOS DE NEGOCIO, 542 
30.1.1. PROCESOS DE NEGOCIOS, 542 
30.1,2. PRINCIPIOS DE REINGENIERÍA DE PROCESOS DE NEGOCIOS, 542 


XXI 


www.elsolucionario.net 


CONTENIDO 


30.1.3. UN MODELO DE RPN, 543 
30.1.4. ADVERTENCIAS, 544 
30.2, REINGENIERÍA DEL SOFTWARE, 544 
30.2.1. MANTENIMIENTO DEL SOFTWARE, 544 
30.2.2. UN MODELO DE PROCESOS DE REINGENIERÍA DEL SOFTWARE, 545 
30.3. INGENIERÍA INVERSA, 547 
30.3.1. INGENIERÍA INVERSA PARA COMPRENDER EL PROCESAMIENTO, 548 
30.32. INGENIERÍA INVERSAPARA COMPRENDER LOS DATOS, 549 
30.3.3. INGENIERÍA INVERSA DE INTERFACES DE USUARIO, 550 
30.4, REESTRUCTURACIÓN, 550 
30.4.1. REESTRUCTURACIÓN DEL CÓDIGO, 550 
30.42, REESTRUCTURACIÓN DE LOS DATOS, 551 
30.5. INGENIERIA DIRECTA (FORWARD ENGINEERING), 551 
30.5.1. INGENIERÍA DIRECTA PARA ARQUITECTURAS CLIENTE/SERVIDOR, 552 
30.5.2. INGENIERÍA DIRECTA PARA ARQUITECTURAS ORIENTADASA OBJETOS, 553 
30.5.3. INGENIERÍA DIRECTA PARA INTERFACES DE USUARIO, 553 
30.6. LA ECONOMÍA DE LA REINGENIERÍA, 554 
RESUMEN, 555 
REFERENCIAS, 555 
PROBLEMAS Y PUNTOS A CONSIDERAR, 556 
OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 556 


CAPÍTULO 31: INGENIERIA DEL SOFTWARE ASISTIDA POR COMPUTADORA, 559 
31.1. ¿QUÉ SIGNIFICA CASE?, 560 
31.2. CONSTRUCCIÓN DE BLOQUES BÁSICOS PARA CASE, 560 
31.3. UNA TAXONOMÍA DE HERRAMIENTAS CASE, 561 
31.4. ENTORNOS CASE INTEGRADOS, 565 
31.5. LA ARQUITECTURA DE INTEGRACIÓN, 566 
31.6. EL REPOSITORIO CASE, 567 
31.6,1. ELPAPEL DEL REPOSITORIO EN 1-CASE, 567 
31.6.2. CARACTERÍSTICAS Y CONTENIDOS, 568 
RESUMEN, 571 
REFERENCIAS, 571 
PROBLEMAS Y PUNTOS A CONSIDERAR, 572 
OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 572 


CAPITULO 32: PERSPECTIVAS FUTURAS. 573 

32.1. IMPORTANCIA DEL SOFTWARESEGUNDA PARTE, 574 
32.2. EL ÁMBITO DEL CAMBIO, 574 
32.3. LAS PERSONAS Y LA FORMA EN QUE CONSTRUYEN SISTEMAS, 574 
32.4. EL«NUEVO» PROCESO DE INGENIERÍA DEL SOFTWARE, 575 
32,35, NUEVOS MODOS DE REPRESENTAR LA INFORMACIÓN, 576 
32.6. LA TECNOLOGIA COMO IMPULSOR, 577 
32.7. COMENTARIO FINAL, 578 

REFERENCIAS, 578 

PROBLEMAS Y PUNTOS A CONSIDERAR, 579 

OTRAS LECTURAS Y FUENTES DE INFORMACIÓN, 579 


APÉNDICE, 581 


ÍNDICE, 589 


XXIT 


www.elsolucionario.net 


ACERCA DEL AUTOR 


proceso del Software y en las tecnologías de la Ingeniería del Software. Durante tres 
décadas, ha trabajado como ingeniero de Software, gestor, profesor, autor y consultor 
centrándose en los temas de la Ingeniería del Softwate. 

Como especialista y gerente industrial, el Dr. Pressman ha trabajado en el desarrollo de sis- 
temas CAD/CAM para aplicaciones avanzadas de ingeniería y fabricación. También ha ocu- 
pado puestos de responsabilidad para programación científica y de sistemas. 

Después de recibir el título de Doctor en Ciencias Físicas en Ingeniería de la Universidad de 
Connecticut, el Dr. Pressman se dedicó a la enseñanza donde llegó a ser Profesor Asociado 
(Bullard Associate Professor) de Informática en la Universidad de Bridgeport y Director del 
Computer-Aided Design an Manufacturing Center en esta Universidad. 

El Dr. Pressman es actualmente el Presidente de R. S. Pressman $ Associates, Inc., una 
empresa de asesoría especializada en métodos y formación de Ingeniería del Softwate. Trabaja 
como asesorjefe, y está especializado en la asistencia a compañías para establecer unas prác- 
ticas eficientes de la Ingeniería del Software. También ha diseñado y desarrollado productos 
para la formación en Ingeniería del Softwate de la compañía y de mejora del proceso: Essen- 
tial Software Engineering, un currículum en vídeo totalmente actualizado que se cuenta entre 
los trabajos industriales más extensos acerca de este tema y, Process Advisor, un sistema pro- 
gramado para la mejora en el proceso de ingeniería del softwate. Ambos productos son utili- 
zados por cientos de compañías mundiales. 

El Dr. Pressman ha escrito numerosos artículos técnicos, participa regularmente en revistas 
industriales, y ha publicado 6 libros. Además de Ingeniería del Software: Un Enfoque Prác- 
tico, ha escrito A Manager”s Guide to Software Engineering (McGraw-Hill), un libro que hace 
uso de un exclusivo formato de preguntas y respuestas para presentar las líneas generales de 
Administración para implantar y comprender la tecnología; Making Software Engineering Hap- 
pen (Prentice-Hall), que es el primer libro que trata los problemas críticos de administración 
asociados a la mejora del proceso del Software y Software Shock (Dorset House), un tratado 
centrado en el Software y su impacto en los negocios y en la sociedad. El Dr. Pressman es miem- 
bro del consejo editorial del ZEEE Software y del Cutter [T Journal, y durante muchos años fue 
editor de la columna «Manager» del IEEE Software. 

El Dr. Pressman es un conocido orador, impartiendo un gran número de conferencias indus- 
triales principalmente. Ha presentado tutoriales en la Conferencia Internacional de Ingeniería 
del Software y en muchas otras conferencias industriales. Es miembro de ACM, IEEE y Tau 
Beta Pi, Phi Kappa Phi, Eta Kappa Nu y Pi Tau Sigma. 


R OGER S. Pressman es una autoridad internacionalmente reconocida en la mejora del 


XXI 


www.elsolucionario.net 


www.elsolucionario.net 


PREFACIO 


UANDO un software de computadora se desarrolla con éxito - cuando satisface las 

necesidades de las personas que lo utilizan; cuando funciona impecablemente durante 

mucho tiempo; cuando es fácil de modificar o incluso es más fácil de utilizar — puede 
cambiar todas las cosas y de hecho las cambia para mejor. Ahora bien, cuando un software de 
computadora falla — cuandolos usuarios no se quedan satisfechos, cuando es propenso a erro- 
res; cuando es difícil de cambiar e incluso más difícil de utilizar — pueden ocurrir y de hecho 
ocurren verdaderos desastres. Todos queremos desarrollar un software que haga bien las cosas, 
evitando que esas cosas malas merodeen por las sombras de los esfuerzos fracasados. Para tener 
éxito al diseñar y construir un software necesitaremos disciplina. Es decir, necesitaremos un 
enfoque de ingeniería. 

Durante los 20 años que han transcurrido desde que se escribió la primera edición de este 
libro, la ingeniería del software ha pasado de ser una idea oscura y practicada por un grupo muy 
pequeño de fanáticos a ser una disciplina legítima de ingeniería. Hoy en día, esta disciplina está 
reconocida como un tema valioso y digno de ser investigado, de recibir un estudio concienzudo 
y un debate acalorado. A través de la industria, el título preferido para denominar al «progra- 
mador» ha sido reemplazado por el de «ingeniero de software». Los modelos de proceso de 
software, los métodos de ingeniería del software y las herramientas del software se han adap- 
tado con éxito en la enorme gama de aplicaciones de la industria. 

Aunque gestores y profesionales reconocen igualmente la necesidad de un enfoque más dis- 
ciplinado de software, continúan debatiendo sobre la manera en que se va a aplicar esta disci- 
plina. Muchos individuos y compañías todavía desarrollan software de manera algo peligrosa, 
incluso cuando construyen sistemas para dar servicio a las tecnologías más avanzadas de hoy 
en día. Muchos profesionales y estudiantes no conocen los métodos nuevos y, como resultado, 
la calidad del software que se produce sufrirá y experimentará malas consecuencias. Además, 
se puede decir que seguirá existiendo debate y controversia a cerca de la naturaleza del enfo- 
que de la ingeniería del software. El estado de la ingeniería es un estudio con contrastes. Las 
actitudes han cambiado y se ha progresado, pero todavía queda mucho por hacer antes de que 
la disciplina alcance una madurez total. 

La quinta edición de la Ingeniería del Software: UnEnfoque Práctico pretende servir de guía 
para conseguir una disciplina de ingeniería madura. Esta edición, al igual que las cuatro ante- 
riores, pretende servir a estudiantes y profesionales, y mantiene su encanto como guía para el 
profesional de industria y como una introducción completa al tema de la ingeniería para alum- 
nos de diplomatura, O para alumnos en primer año de segundo ciclo. El formato y estilo de la 
quinta edición ha experimentado cambios significativos, con una presentación más agradable 
y cómoda para el lector, y con un contenido de acceso más fácil. 

La quinta edición se puede considerar más que una simple actualización. La revisión de este 
libro se ha realizado para adaptarse al enorme crecimiento dentro de este campo y para enfati- 
zar las nuevas e importantes prácticas de la ingeniería del software. Además, se ha desarrollado 
un sitio Web con todo lo necesario y esencial para complementar el contenido del libro. Junto 
con la quinta edición de Ingeniería del Software: Un Enfoque Práctico, la Web proporciona 
una gama enorme de recursos de ingeniería del software de la que se beneficiarán instructores, 
estudiantes y profesionales de industria. 

La estructura de la quinta edición se ha establecido en cinco partes y la intención ha sido la 
de realizar una división por temas, y ayudar así a instructores que quizás no tengan tiempo de 
abarcar todo el libro en un solo trimestre. La Parte Primera, El producto y el proceso, es una 
introducción al entorno de la ingeniería del software. La intención de esta parte es introducir el 
tema principal y, lo que es más importante, presentar los conceptos necesarios para los capítu- 
los siguientes. La Parte Segunda, Gestión de proyectos de software, presenta los temas rele- 
vantes para planificar, gestionar y controlar un proyecto de desarrollo de ingeniería. La Parte 
Tercera, Métodos convencionales para la ingeniería del software, presenta los métodos clási- 
cos de análisis, diseño y pruebas considerados como la escuela «convencional» de la ingenie- 
ría del software. La Parte Cuarta, Ingeniería del software orientada a objetos, presenta los 
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métodos orientados a objetos a lo largo de todo el proceso de ingeniería del software, entre los 
que se incluyen análisis, diseño y pruebas. La Parte Quinta, Temas avanzados en ingeniería del 
software, introduce los capítulos especializados en métodos formales, en ingeniería del soft- 
ware de sala limpia, ingeniería del software basada en componentes, ingeniería del software 
cliente/servidor, ingeniería de Web, reingeniería y herramientas CASE. 

La estructura de la quinta edición en cinco partes permite que el instructor «agrupe» los temas 
en función del tiempo disponible y de las necesidades del estudiante. Un trimestre completo se 
puede organizar en tomo a una de las cinco partes. Por ejemplo, un «curso de diseño» podría 
centrarse solo en la Parte Tercera O Cuarta; un «curso de métodos» podría presentar los capí- 
tulos seleccionados de las Partes Tercera, Cuarta y Quinta. Un «curso de gestión» haría hinca- 
pié en las Partes Primera y Segunda. Con la organización de esta quinta edición, he intentado 
proporcionar diferentes opciones para que el instructor pueda utilizarlo en sus clases. 

El trabajo que se ha desarrollado en las cinco ediciones de Ingeniería del Software: UnEnfo- 
que Práctico es el proyecto técnico de toda una vida. Los momentos de interrupción los he dedi- 
cado a recoger y organizar información de diferentes fuentes técnicas. Por esta razón, dedicaré 
mis agradecimientos a muchos autores de libros, trabajos y artículos, así como a la nueva gene- 
ración de colaboradores en medios electrónicos (grupos de noticias, boletines informativos elec- 
trónicos y World Wide Web), quienes durante 20 años me han ido facilitando otras visiones, 
ideas, y comentarios. En cada uno de los capítulos aparecen referencias a todos ellos. Todos 
están acreditados en cuanto a su contribución en la rápida evolución de este campo. También 
quiero dedicar mis agradecimientos a los revisores de esta quinta edición. Sus comentarios y 
críticas son de un valor incalculable. Y por Último dedicar un agradecimiento y reconocimiento 
especiales a Bruce Maxim de la Universidad de Michigan —DearBorn, quien me ayudó a desa- 
rrollar el sitio Web que acompaña este libro, y como persona responsable de una gran parte del 
diseño y contenido pedadógico—. 

El contenido de la quinta edición de Ingeniería del Software: UnEnfoque Práctico ha tomado 
forma gracias a profesionales de industria, profesores de universidad y estudiantes que ya habían 
utilizado las ediciones anteriores, y que han dedicado mucho tiempo en mandarme sus suge- 
rencias, críticas e ideas. Muchas gracias también a todos vosotros. Además de mis agradeci- 
mientos personales a muchos clientes de industria de todo el mundo, quienes ciertamente me 
enseñan mucho más de lo que yo mismo puedo enseñarles. 

A medida que he ido realizando todas las ediciones del libro, también han ido creciendo y 
madurando mis hijos Mathew y Michael. Su propia madurez, carácter y éxito en la vida han 
sido mi inspiración. Nada me ha llenado con más orgullo. Y, finalmente, a Bárbara, mi cariño 
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Roger $, Pressman 


www.elsolucionario.net 


PREFACIO 


Siempre he admirado la profundidad del contenido y la habilidad del autor para descri- 
bir datos difíciles de forma muy clara. De manera que tuve el honor de que McGraw- 

Hill me pidiera elaborar la Adaptación Europea de esta quinta edición. Esta es la tercera 

adaptación, y su contenido es un acopio de la quinta edición americana y el material que yo 

mismo he escrito para ofrecer una dimensión europea. 

Las áreas del libro que contienen ese material extra son las siguientes: 
+. Existe una gran cantidad de material sobre métodos formales de desarrollo del software. 

Estas técnicas fueron pioneras en el Reino Unido y Alemania, y han llegado a formar parte 

de los juegos de herramientas críticos para los ingenieros de software en el desarrollo de sis- 

temas altamente integrados y críticos para la seguridad. 

+ He incluido una sección sobre patrones de diseño. Estos son los que tienen lugar general- 
mente en miniarquitecturas que se dan una y otra vez en sistemas orientados a objetos, y que 
representan plantillas de diseño que sereutilizaránuna y otra vez. He viajado por toda Europa, 
y me he encontrado constantemente compañías cuyo trabajo depende realmente de esta tec- 
nología. 

+. He aportado material sobre métricas y en particular la utilización de GQM como métrica de 
método de desarrollo. A medida que la ingeniería del software se va integrando poco a poco 
dentro de una disciplina de ingeniería, esta tecnología se va convirtiendo en uno de sus fun- 
damentos. La métrica ha sido uno de los puntos fuertes en Europa de manera que espero que 
toda la dedicación que he puesto en este tema lo refleje. 

+ He incluido también material sobre el Lenguaje de Modelado Unificado (UML) el cual refleja 
el gran incremento de utilización de este conjunto de notaciones en Europa Occidental. Ade- 
más, sospecho que van a ser de hecho las notaciones de desarrollo de software estándar 
durante los próximos tres o cuatro años. 

+ He dado mayor énfasis al desarrollo de sistemas distribuidos mediante el lenguaje de pro- 
gramación Java para ilustrar la implicación de algunos de los códigos. Ahora que Internet y 
el comercio electrónico están en pleno auge en Europa, las compañías cada vez se vuelcan 
más en las técnicas de ingeniería del software al desarrollar aplicaciones distribuidas. Y esto 
también queda reflejado en el libro. 

+. He incluido también material sobre métodos de seguridad e ingeniería. Con la utilización de 
Intemet (una red abierta) todos los ingenieros del software tendrán que saber muchas más 
técnicas tales como firmas digitales y criptografía. 

+ Hacia el final del libro he hecho especial hincapié en la utilización de aplicaciones de comer- 
cio electrónico para mostrar de esta manera la tecnología distribuida. 

Existen dos partes que hacen referencia al libro: un sitio Web americano muy importante, desa- 
rrollado por el Dr. Pressman; y un sitio de entrada, cuya dirección se proporciona a lo largo de todo 
el libro al final de cada capítulo. Este sitio contiene el material relevante para la edición europea y 
los enlaces con el sitio americano. Ambos sitios Web en combinación contienen sub-Webs con recur- 
sos para Estudiantes, para Profesores y para Profesionales. 

En los Recursos para el estudiante se incluye una guía de estudio que resume los puntos clave 
del libro, una serie de autopruebas que permiten comprobar la comprensión del material, cientos 
de enlaces a los recursos de ingeniería del software, un caso práctico, materiales complementarios 
y un tablón de mensajes que permite comunicarsecon otros lectores. 

En la parte Recursos para el profesor se incluye una guía para el instructor, un conjunto de 
presentaciones en PowerPoint basadas en este libro, un conjunto de preguntas que se pueden 
utilizar para practicar mediante deberes y exámenes, un conjunto de herramientas muy peque- 
ñas (herramientas sencillas de ingeniería del software adecuadas para su utilización en clase), 
una herramienta de Web que permite crear un sitio Web específico para un curso, y un tablón 
de mensajes que hace posible la comunicación con otros instructores. 

En los Recursos para profesionales se incluye documentación para los procesos de inge- 
niería del software, listas de comprobación para actividades tales como revisiones, enlaces a 
proveedores de herramientas profesionales, cientos de enlaces a recursos de ingeniería del soft- 
ware, información sobre los paquetes de vídeo de Pressman, y comentarios y ensayos indus- 
triales acerca de varios temas de la ingeniería del software. 

Ingeniería del software es un libro excelente, y espero que los aportes que he incluido para 
el lector europeo hagan de este libro una lectura obligada. 


E L libro de Roger Pressman sobre Ingeniería del software es verdaderamente excelente: 


Darrel Ince 
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EL ESTADO DEL ARTE DE LA INGENIERÍA DEL SOFTWARE 


La Ingeniería de/l Software' es una disciplina o área de la Informática o Ciencias de la Com- 
putación, que ofrece métodos y técnicas para desarrollar y mantener software de calidad que 
resuelven problemas de todo tipo. Hoy día es cada vez más frecuente la consideración de la 
Zngenierh de/l Software como una nueva área de la ingeniería, y el ingeniero de/l software 
comienza a ser una profesión implantada en el mundo laboral internacional, con derechos, debe- 
res y responsabilidades que cumplir, junto a una, ya, reconocida consideración social en el 
mundo empresarial y, por suerte, para esas personas con brillante futuro. 

La Ingeniería de/l Software trata con áreas muy diversas de la informática y de las ciencias 
de la computación, tales como construcción de compiladores, sistemas operativos o desarro- 
llos en Intranet/Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier 
tipo de sistemas de información y aplicables a una infinidad de áreas tales como: negocios, 
investigación científica, medicina, producción, logística, banca, control de tráfico, meteorolo- 
gía, el mundo del derecho, la red de redes Intemet, redes Intranet y Extranet, etc. 


Definición del término «Ingeniería de/l Software» 


El término Zngenierh se define en el DRAE? como: «1. Conjunto de conocimientos y técni- 
cas que permiten aplicar el saber científico a la utilización de la materia y de las fuentes de 
energía. 2. Profesión y ejercicio del ingeniero» y el término ingeniero se define como «1, Per- 
sona que profesa o ejerce la ingeniería». De igual modo la Real Academia de Ciencias Exac- 
tas, Físicas y Naturales de España define el término Ingeniería como: «Conjunto de 
conocimientos y técnicas cuya aplicación permite la utilización racional de los materiales y 
de los recursos naturales, mediante invenciones, construcciones u otras realizaciones prove- 
chosas para el hombre»?. 

Evidentemente, si la Ingeniería del Software es una nueva ingeniería, parece lógico que reúna 
las propiedades citadas en las definiciones anteriores. Sin embargo, ni el DRAE ni la Real Aca- 
demia Española de Ciencias han incluido todavía el término en sus Ultimas ediciones; en con- 
secuencia vamos a recurrir para su definición más precisa a algunos de los autores más acreditados 
que comenzaron en su momento a utilizar el término o bien en las definiciones dadas por orga- 
nismos internacionales profesionales de prestigio tales como IEEE o ACM. Así, hemos selec- 
cionado las siguientes definiciones de Zngenierh del Software: 


Definición 1 


Ingeniería de Software es el estudio de los principios y metodologías para desarrollo y man- 
tenimiento de sistemas de software [Zelkovitz, 19787f, 


Definición 2 


Ingeniería del Software es la aplicación práctica del conocimiento científico en el diseño 
y construcción de programas de computadora y la documentación asociada requerida para 
desarrollar, operar (funcionar) y mantenerlos. Se conoce también como desarrollo de soft- 
ware o producción de software [Bohem, 19761", 


1 En Hispanoamérica. el término utilizado normalmente es: Ingeniería de Software. 

2 DRAE, Diccionariode la Real Academia Española de la Lengua. 

3 Vocabulario Científico y Técnico, edición de 1996. 

* ZeLkovITZ, M, V., CHAW, A. C, Y GANNON,J. D,: Principles of Software Engineering and Design. Prentice-Hall, Englewoods 
Ciif, 1979. 

5 Bozm, B. W.: «Software Engineering», ¡EEE Transactions on Computers, C-25, núm. 12, diciembre, pp. 1226-1241. 
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Definición 3 


Ingeniería del Software trata del establecimiento de los principios y métodos de la ingenie- 
ría a fin de obtener software de modo rentable que sea fiable y trabaje en máquinas reales [Bauer, 
19721”. 


Definición 4 


La aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, opera- 
ción (funcionamiento) y mantenimiento del software; es decir, la aplicación de ingeniería al 
software. 2. El estudio de enfoques como en (1) [IEEE, 19931”. 


Tomando como base la referencia de estas definiciones seleccionadas, se producen de inme- 
diato las preguntas: ¿cuáles son las actividades que se encuadran hoy día en el mundo de la 
ingeniería del software? y ¡cómo se enseña la disciplina de ingeniería del software en las uni- 
versidades, escuelas de ingenieros e institutos tecnológicos? 

La respuesta a la primera pregunta se manifiesta de muy diversas formas, pero creemos que 
tal vez las fuentes más objetivas sean las conferencias, eventos y acontecimientos internaciona- 
les más relevantes realizados en estos Últimos años. Así, de los estudiados, hemos considerado 
como congresos significativos, los convocados por SIGSOFT (Special Interest Group on Soft- 
ware Engineering) de la ACM*: Intemational Conferenceon Software Engineering (ICSE,copa- 
trocinada con IEEE) celebrada en Boston, Massachussets, USA (17-23 de mayo de 1997) y la 
próxima conferencia anunciada para celebrarse en 1998en Kyoto, Jápón (ICSE, 19-25 de abril 
de 1998); 5.” Symposium Foundations of Software Engineering, SIGSOFT 97 (Zurich, 22-25 
septiembre de 1997) y 6." Symposium SIGSOFT 98 (Orlando, Florida, USA, 3-5 noviembre de 
1998). 

En los congresos citados anteriormente y en algunas otras fuentes como revistas de ACM/IEE 
y otras de tipo profesional o comercial específicas de ingeniería de software, hemos analizado 
sus programas, tutoriales, talleres de trabajo, contenidos, etc., y hemos seleccionado una lista 
con los temas más candentes del actual estado del arte de la ingeniería del Software. Los temas 
más sobresalientes son: 


» Inspección de software crítico. 

. Software de Tecnologías de Procesos de Negocios. 

. Arquitecturas de Software Distribuido. 

» Introducción a UML (Metodología de objetos, método unificado de Booch, Rumbaugh y 
Jacobson). 

» Control técnico de proyectos software. 

+ Marcos de trabajo (frameworks) de empresa orientados a objetos. 

» Una introducción a CORBA (Estándar para objetos distribuidos). 

« Estrategias de ingeniería inversa para migración de software. 

» Ingeniería de objetos. 

.« Modelado y análisis de arquitectura de software. 

» Objetos distribuidos. 

. Sistemas Cliente/Servidor. 

. Reingeniería. 

+ CASE. 

» Análisis y Diseño Orientados a Objetos. 


Esta cuarta edición ha mejorado en cantidad y calidad a la tercera edición, pero su actuali- 
dad en el año 1997, reside en el hecho de que la mayoría de temas tratados o que se van a tra- 
tar en los congresos de la ACM (listados anteriormente), están contemplados y tratados por el 
autor en este libro. En cualquier forma, deseamos destacar muy expresamente algunas mejoras 
concretas que vienen a llenar una importante laguna que existía en los libros de ingeniería del 


£ BAUER, F. L.: «Software Engineering», Information Processing, 71, North Holland PubiishingCo., Amsterdarn, 1972 
? TEEE: Standards Collection: Software Engineering, IEEE Standard 610.12-1990, IEEE, 1993. 
$ URL de ACM, http://www.acm.org. 
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software en inglés y, por supuesto, en español. Así, destacamos el estudio y profundidad que 
se hace de temas tan candentes y de actualidad en el mundo de la ingeniería del software tales 
como: Métodosformales, reutilización de software, reingeniería, métodos de software Cliente/Ser- 
vidor, CASE, análisisldiseñolpruebas y métricas orientados a objetos, etc., junto con un epí- 
logo donde muestra el estado actual y futuro de la Ingeniería del Software. Con relación a la 
tercera edición se aprecia una consolidación de tratamientos y una unificación de bloques de 
conocimiento que consiguen mejorar el aprendizaje del lector. 

Una de las aportaciones más relevantes que aporta esta nueva edición es la excelente biblio- 
grafía y referencias bibliográficas que se adjuntan en cada capítulo del libro, junto a una nove- 
dad que poco a poco comienza a incorporarse en las buenas obras científicas y que aquí alcanza 
un excelente nivel: direcciones electrónicas (URLs) de sitios Webde Internet notables, donde 
se pueden ampliar conocimientos, fuentes bibliográficas, consultorías, empresas, organismos 
internacionales, etc., especializados en Ingeniería de Software. 

En lo relativo a la segunda pregunta antes enunciada, su respuesta implica el uso de libros 
de texto y manuales que ayuden al estudiante a complementar las lecciones impartidas por el 
profesor, así como preparar sus trabajos, prácticas, exámenes, etc. Un libro para ser conside- 
rado de texto o referencia de una determinada asignatura requiere que su contenido contenga 
todos o la mayoría de los descriptores o tópicos considerados en el programa de la asigna- 
tura. Veamos por qué esta obra es idónea como libro de texto para asignaturas del cum'culum 
universitario de Ingeniería de/l Software. 


EL LIBRO COMO TEXTO DE REFERENCIA UNIVERSITARIA 


La importancia fundamental de la disciplina /ngeniería del Software se está manifestando, de modo 
destacado, en los currículum de informática y ciencias de la computaciónde la mayoría de las uni- 
versidades de todo el mundo, y seguirá creciendo su importancia a medida que nos acerquemos 
al tercer milenio. 

Debido a estas circunstancias, las organizaciones profesionales, los departamentos educati- 
vos de los diversos gobiernos y los departamentos universitarios se han preocupado en esta 
década y en las anteriores de estandarizar los programas curriculares de las diferentes carreras, 
incluyendo materias (asignaturas) troncales y obligatorias, en los planes de estudios de Facul- 
tades y Escuelas de Ingenieros de todo el mundo. 

El caso más significativo lo constituyen las organizaciones profesionales internacionales que 
se han preocupado también de este proceso. Entre las más destacadas sobresalen ACM (Asso- 
ciation of Computing Machinery) e IEEE (Institute for Electrical and Electronics Engineers). 
Así, en el año 1991,estas dos organizaciones publicaron conjuntamente unas recomendacio- 
nes con los requisitos (materias) imprescindibles que, al menos, debían contemplar todos los 
planes de estudios de carreras relacionadas con Ciencias de la Computación (Informática). Estas 
recomendaciones han sido seguidas por todas las universidades de Estados Unidos y práctica- 
mente, de una u otra forma, por casi todas las universidades europeas e hispanoamericanas, 
desde el año de su publicación. 

Las recomendaciones ACM/IEEE ' dividen los requisitos del currículum en nueve áreas dife- 
rentes, con subdivisiones en esas áreas. Para cada subárea se recomienda un número mínimo 
de unidades de conocimiento (knowledge units) con una indicación de tiempo para cada una de 
ellas (períodos de 50 minutos/clase). En estas nueve áreas se incluyen: Algoritmos, Arquitec- 
tura, Inteligencia Artificial, Bases de Datos, Interfaces Hombre/Máquina, Computación numé- 
rica, Sistemas Operativos, Programación, Ingeniería del Software, Lenguajes de Programación 
y Temas legales, profesionales y sociales. Los temas recomendados en el área de Ingeniería de 
Software son: 


Conceptos fundamentales de resolución de problemas. 
Proceso de desarrollo de software. 

Especificaciones y requisitos de software. 

Diseño e implementación de software. 

Verificación y validación. 


APUNTA 


2 http: /www acm.org ; http:/xavier.xu.edu:8000/--lewan/new cum'culum.html 
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En España, el Consejo de Universidades, organismo encargado de dictar directrices y nor- 
mas para los planes de estudios de las universidades tiene redactadas las normativas que han 
de cumplir todas las universidades que deseen impartir las carreras de Ingeniería en Informá- 
tica (cinco años académicos, diez semestres), Ingeniería Técnica en Informática de Sistemas e 
Ingeniería Técnica en Informática de Gestión (tres años académicos, seis semestres) y se publi- 
can oficialmente en el Boletín Oficial del Estado (BOE).En estas normativas de obligado cum- 
plimiento por todas las universidades, se incluyen las materias (asignaturas o conjunto de 
asignaturas) troncales que se deben incluir obligatoriamente en todos los planes de estudios, 
además de otras asignaturas con carácter obligatorio y opcional que cada universidad fija en 
sus planes de estudios. 

Ingeniería del Software es una materia troncal incluida en las carreras citadas. 18 créditos 
(cada crédito equivale a diez horas de clase) en la ingeniería superior (ingeniero informútico) 
y 12créditos en la ingeniería técnica de informática de gestión (ingeniero técnico informútico). 
Esto significa una carga lectiva considerable que todos los estudiantes de carreras de informá- 
tica y de computación han de estudiar, normalmente en los cursos 3, a 5.” 

Este libro puede ser utilizado en diferentes tipos de cursos de ingeniería de software tanto a 
nivel universitario como a nivel profesional: 


1, Cursos introductorios de Ingeniería del Software. Estudiantes de primer ciclo (tres años) 
y segundo ciclo (cinco años), o en carreras de cuatro años (como suele ser el caso de las 
universidades hispanoamericanas y alguna española), sin experiencia previa en Ingenie- 
ría del Software, pero con formación de dos o tres cursos universitarios (cuatro o cinco 
semestres) al menos. 

2. Cursos introductorios y de nivel medio sobre temas específicos de Ingeniería del Soft- 
ware tales como análisis de requisitos y especificaciones, gestión de proyectos de soft- 
ware, métodos convencionales de Ingeniería del Software, etc. 

3. Cursos avanzados en temas de Ingeniería del Software tales como: análisis y diseño orien- 
tados a objetos, métricas, ingeniería inversa, Cliente/Servidor, Reutilización de software, 
etcétera. 


Este libro explica todos los temas incluidos en la asignatura O materia troncal Ingeniería del 
Software por el Consejo de Universidades de España, así como las unidades SE2a SES (la uni- 
dad SEl se refiere a conceptos de tipo general que suelen incluirse en otras asignaturas bási- 
cas) del currículum de la ACM/IEEE de 1991.Por nuestro conocimiento personal (conferencias, 
cursillos, estancias...) de muchas universidades hispanoamericanas, nos consta que los planes 
de estudio de estas universidades incluyen también asignaturas de tipo obligatorio de Ingenie- 
ría del Software que siguen prácticamente las recomendaciones de ACM/TEEE y son muy simi- 
lares a los programas que se siguen también en España. 


APÉNDICE 


La obra actual incluye gran cantidad de siglas y acrónimos en inglés, la mayoría de las cuales, 
exceptuando las ya acreditadasen inglés cómo BPR..., se han traducido al español. Por su espe- 
cial importancia y la gran cantidad de ellas incluidas en el libro, el equipo de traducción decidi- 
mos recopilar todas las siglasen inglés y sus traducciones al español; a continuaciónse ha construido 
dos tablas ordenadas alfabéticamente en inglés y en español, con el objetivo principal de que el 
lector pueda localizar fácilmente cualquiera de las siglas que aparecen en el texto, y en su caso, 
la traducción al español. Estas tablas se presentaron a la editora de la obra que tras ver el servicio 
que proporcionaba al lector, aceptó incluirlascomo Apéndice. De este modo, el lector podrá com- 
probar en cualquier momento entradas de siglas tanto en español como en inglés. 


EPÍLOGO 


La traducción de esta obra ha sido un esfuerzo común que hemos realizado profesores de dife- 
rentes universidades españolas e hispanoamericanas — profesores de Ingeniería del Software 
que hemos utilizado, en la mayoría de los casos, las ediciones anteriores de esta obra como libro 
de referencia en nuestras clases y continuaremos utilizándolo. Por esta circunstancia, hemos 
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podido apreciar que esta cuarta edición ha mejorado de modo muy notable a las ediciones ante- 
riores y tenemos el convencimiento de que los principios y conceptos considerados en ella, 
seguirán teniendo una influencia considerable en numerosos estudiantes de ingeniería, licen- 
ciatura informática o sistemas computacionales de habla española, como nos consta que siguen 
influyendo en el mundo de habla inglesa. Estamos seguros de que serán muchos los estudian- 
tes que seguirán formándose en Ingeniería del Software con este libro como referencia funda- 
mental. 

Esta cuarta edición llena numerosas lagunas en la literatura de habla española, ya que actua- 
liza los contenidos tradicionales de la Ingeniería del Software y los extiende a los temas avan- 
zados modernos que ya hemos considerado. El excelente trabajo de Roger $, Pressman permitirá 
seguir formando numerosos y buenos profesionales de Ingeniería del Software para que esta 
industria pueda seguir desarrollándose. 


Madrid, septiembre de 1997 


Luis Joyanes Aguilar 

Director del Departamento de Lenguajes y Sistemas Informáticos 
e Ingeniería del Software 

Facultad de Informática y Escuela Universitaria de Informática 
Universidad Pontificia de Salamanca. Campus de Madrid 
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era del conocimiento en que vivimos no sólo está cambiando la sociedad en sí misma, 
sino que los nuevos modelos de negocios requieren la reformulación de nuevos con- 
ceptos. Conocimiento, activos intangibles, Web, etc., son algunos de los términos más utiliza- 
dos en cualquier ambiente o negociación. Esta era del conocimientorequiere de nuevas tendencias 
apoyadas precisamente en el conocimiento. La ingeniería del software no es una excepción, y 
por ello se requiere no sólo una actualización de conceptos, sino también una comprensión y 
una formulación del nuevo conocimiento existente en torno a las nuevas innovaciones y teo- 
rías de dicha disciplina. 
En cada edición de su clásica obra, Roger Pressman nos tiene acostumbrados a la sorpresa 
y ala admiración por la clara y excelente exposición de los temas tratados. Esta vez tampoco 
ha sido una excepción, muy al contrario, Pressman da la sensación de haber conseguido «la 
cuadratura del círculo» o mejor aún, ha encontrado la piedra filosofal para formar y educar a 
los actuales y —sobre todo — futuros ingenieros de software del futuro (o a los ingenieros infor- 
máticos e ingenieros de sistemas y licenciados en informática que se forman en esta disciplina). 
En esta quinta edición, Pressman proporciona al lector una ingente cantidad de conocimiento 
relativo a ingeniería del software que facilitará considerablemente su formación con todo el 
rigor profesional y científico que requiere la nueva era del conocimiento que viviremos en esta 
década. 


| L siglo XX1 se enfrenta a la creciente implantación de la sociedad del conocimiento. La 


EL NUEVO CONTENIDO 


Una de las grandes y atractivas novedades de esta quinta edición es su nuevo formato y estilo. 
El SEPA 5/2, como se le conoce en la versión en inglés, ha mejorado el libro y lo ha hecho más 
legible y atractivo al lector. Mediante iconos y una lista normalizada de seis cuestiones clave, 
Pressman va guiando al lector sobre los temas mas importantes de cada capítulo a la vez que 
su lectura le introduce paulatina e inteligentemente en las ideas y conceptos más importantes. 
Esta quinta edición contiene todos los temas importantes de la cuarta edición e introduce una 
gran cantidad de temas relativos a las nuevas tendencias, herramientas y metodologías que plan- 
tea la ingeniería de software actual y futura, así como la naciente nueva ingeniería Web. Un 
estudio detenido del contenido nos conduce a los cambios más sobresalientes realizados en esta 
quinta edición, que son, entre otros, los siguientes: 


» Cinco nuevos capítulos (Capítulo 14, Diseño arquitectónico; Capítulo 15, Diseño de la 
interfaz de usuario, proporcionando reglas de diseño, procesos de modelado de interfaces, 
diseño de tareas y métodos de evaluación; Capítulo 16, Diseño a nivel de componentes; 
Capítulo 27, examina los procesos y la tecnología de la ingeniería de software basada en 
componentes, y, Capítulo 29, que presenta los nuevos conceptos de Ingeniería Web (proce- 
sos WebE, análisis y formulación de aplicaciones Web, es decir arquitectura, navegación y 
diseño de interfaces, pruebas y aplicaciones Web y gestión de proyectos de ingeniería Web). 

+ Gran cantidad de actualizaciones y revisiones de los 32 capítulos de su contenido total. 
Los cambios clave son numerosos, y los más sobresalientes son: 


— Modelos de procesos evolutivos (WinWin) y de ingeniería basada en componentes. 
— Nuevas secciones sobre control estadístico de la calidad. 

— Modelo de estimación de COCOMO 11. 

—Técnicas a prueba de errores para gestión de calidad de software (SQA). 
—Ingeniería de requisitos. 

—El lenguaje unificado de modelado, UML (Unified Modeling Language). 

— Nuevas regias y teoría de calidad de software que siguen la normativa ISO 9000. 
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NUEVOS RECURSOS DOCENTES Y PROFESIONALES 


Si la edición en papel que tiene el lector en sus manos ya es de por sí excelente, el sitio Web 
del libro no le queda a la zaga (www.pressmanS.com). Este sitio es una de las mejores herra- 
mientas de las que pueden disponer estudiantes, profesores y maestros, y profesionales del 
mundo del software. Destaquemos algunas. 


Recursos de estudiantes 


+ Guía de estudios. 

Autotest. 

+. Recursos basados en la Web. 

+ Estudio de casos. 

» Vídeos. 

» Contenidos suplementarios. 

+ Foros para intercambios de mensajes entre lectores. 


Recursos de profesores y maestros 


» Guía del profesor. 

» Transparencias (acetatos) en PowerPoint. 

+ Bancos de prueba. 

+ Herramientas de ingeniería de software. 

+ Foros de intercambio de mensajes entre colegas. 


Recursos profesionales 


» Plantillas de productos de documentos y de trabajos. 
+ Listas de pruebas de ingeniería de software. 

+ Herramientas de ingeniería de software. 

» Herramientas CASE. 

» Recursos de ingeniería de software. 

+ Modelos de procesos adaptables. 

» Currículum de vídeos de calidad para la industria. 

» Comentarios de la industria. 

+ Foros profesionales. 


EL GLOSARIO DE SIGLAS: UN NUEVO APÉNDICE 


Una de las características más sobresalientes de esta obra es que recoge con gran profusión la 
ingente cantidad de siglas que hoy día se utilizan en la industria del softwarejunto a otras muchas 
más acuñadas por el propio autor. 

El equipo de profesores que ha traducido y adaptado la versión en inglés de común acuerdo 
con la editora acordó realizar un apéndice que incluyera todas las siglas incluidas en el libro y 
las traducciones correspondientes en español, y viceversa. Este apéndice busca, al igual que ya 
se hiciera en la segunda edición en español, facilitar al lector la lectura y seguimiento del modo 
más fácil posible y que le permita hacer la correspondencia entre ambos idiomas cuado lo nece- 
site. Por ello, este apéndice contiene un diccionario inglés-español y otro español-inglés de 
siglas. El método que se ha seguido durante la traducción ha sido traducir prácticamente todas 
las siglas, y sólo se han realizado algunas excepciones, como SQA (Software Quality Assure- 
ment) por su uso frecuente en lajerga informática, aunque en este caso hemos utilizado ambos 
términos (en inglés, SQA y en español, GCS, Gestión de Calidad del Software). En este caso, 
estas siglas en español coinciden con Gestión de Configuración del Software (GCS), por lo que 
a veces estas siglas se han traducido por GCVS (Gestión de Configuración de Versiones de Soft- 
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PRÓLOGO A LA QUINTA EDICiux ri oran 


ware) para evitar duplicidades. Ésta es una de las razones fundamentales por la que hemos 
incluido el glosario de siglas. 


EL EQUIPO TRADUCTOR 


La edición británica ha sido adaptada por un prestigioso profesor británico, y la edición y la 
adaptación españolas han sido realizadas por un numeroso equipo de profesores del Departa- 
mento de Lenguajes y Sistemas Informáticos e ingeniería del Software de la Facultad de infor- 
mática y Escuela Universitaria de Informática de la Universidad Pontificia de Salamanca 
(España) del campus de Madrid, que ha contado con la inestimable colaboración de profeso- 
res del prestigioso Instituto Tecnológico (TEC) de Monterrey, de su campus de Querétaro 
(México). Una obra de la envergadura de esta quinta edición requería —como ya sucedió tam- 
bien en la edición anterior — del trabajo y coordinación de numerosas personas. Muchas han 
sido las horas dedicadas a la traducción, adaptación y sucesivas revisones de galeradas de las 
pruebas de imprenta. Confiamos haber cumplido nuestra obligación con dignidad y profesio- 
nalidad. 


EL FUTURO ANUNCIADO 


Esta quinta edición ha sido actualizada sustancialmente con nuevos materiales que reflejan el 
estado del arte de la ingeniería del software. El material obsoleto se ha eliminado de esta edi- 
ción para crear un texto fácil de leer y entender, y totalmente actualizado. Sin embargo, y con 
ser importante todo su vasto y excelente contenido, queremos destacar que esta nueva edición 
nos brinda y abre el camino al futuro que señala la moderna ingeniería de software basada en 
objetos y componentes, así como a la ingeniería Web, conservando el rigor y la madurez de las 
teorías ya clásicas de la ingeniería del software. 

Sin lugar a dudas, Pressman ha conseguido una excelente obra, y en una prueba clara de pro- 
fesionalidad y excelencia ha logrado superar sus cuatro ediciones anteriores ya de por sí exce- 
lentes. 


Madrid y Carchelejo (España ), verano de 2001 
Luis Joyanes Aguilar 
Director del Departamento de Lenguajes, Sistemas informáticos e Ingeniería de Software 


Facultad de Informática/Escuela Universitaria de Informática 
Universidad Pontificia de Salamanca campus Madrid 
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UTILIZACIÓN DEL LIBRO 


A quinta edición de Ingeniería del Software: UnEnfoque Práctico se ha vuelto a diseñar para aumentar la 

experiencia del lector y para proporcionar enlaces integrados al sitio Web, http://www.pressman5.com. 

Dentro de este sitio los lectores encontrarán información complementaria útil y rica, y una gran cantidad 
de recursos para los instructores que hayan optado por este libro de texto en clase. 


A lo largo de todo el libro se van encontrando iconos que deberán interpretarse de la siguiente manera: 


$ El icono de punto clave ayudará El icono Referencia web propor- 
: a encontrar de forma rápida los ciona punteros directos a sitios 
CLAVE puntos importantes. Web importantes relacionados con 


Referencia Web 


Para punteros que conducirán 
directamente a los recursos de la Web. 


Utlizadopara enfarizar un punto impor- la ingeniería del software. 


tante en el cuerpo del texto. 


El icono de consejo proporciona 


Eonsuo) 


Unconsejopráctico de/mundoredapl; 


codo” lg ingeniería del softwore. 


Ed ¿En dónde puedo . 
encontrar (0 Tespuesta? 


Referencia cruzada 


Proporciona una referencia cruzada impor- 
tonte dentro del libro 


una guía pragmática que serviráde 
ayuda para tomar la decisión ade- 
cuada o evitar los problemas típi- 
cos al elaborar software. 


El icono de signo de interroga- 
ción formula preguntas que se res- 
ponderán en el cuerpo del texto. 


El icono de referencia cruzada 
nos conducirá a alguna otra parte 
del texto en donde se podrá encon- 
trar información relevante sobre 
el tema en cuestión. 


Untema seleccionado. 


lista de comprobación 


E 


El icono de sitio Web indica que 
se dispone de más información 
sobre el tema destacado en el sitio 
Web SEPA. 


El icono de lista de comproba- 
ción nos señala las listas de com- 
probación que ayudan a evaluar el 
trabajo de ingeniería del software 
que se está llevando a cabo y los 
productos del trabajo. 


El icono de documento nos seña- 
la los bocetos, descripciones y 
ejemplos de documentos del sitio 


El icono de cita presenta citas = Web SEPA. 
interesantes que tienen gran rele- S 
vancia para los temas que se estén 

Documento 


tratando. 


XXXVII 


www.elsolucionario.net 


PARTE 


www.elsolucionario.net 


EL PRODUCTO 
Y EL PROCESO 


-N esta parte de Ingeniería del software: un enfoque práctico aprenderá 
sobre el producto que va a ser tratado con ingeniería y el proceso que 
proporciona un marco de trabajo para la tecnología de Ingeniería del 


software. En los capítulos siguientes se tratan las preguntas: 


¿Qué es realmente el software de computadora? 


¿Por qué se lucha para construir sistemas de alta calidad basados en com- 
putadoras? 


¿Cómo se pueden establecer categorías de dominios de aplicaciones para 
software de computadoras? 


¿Qué mitos de software van a existir? 

¿Qué es un «proceso» de software? 

¿Existe una forma genérica de evaluar la calidad de un proceso? 

¿Qué modelos de procesos se pueden aplicar al desarrollo del software? 
¿En que difieren los modelos de proceso lineales e iterativos? | 
¿Cuáles son sus puntos fuertes y débiles? | 


¿Qué modelos de proceso avanzados se han propuesto para la ingeniería 
del software? 


Una vez contestadas todas estas preguntas, estará más preparado para com- 


prender los aspectos técnicos y de gestión de la disciplina de ingeniería a la que 
se dedica el resto del libro. 
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CAPÍTULO 


EL PRODUCTO 


AS alarmas comenzaron más de una década antes del acontecimiento. Con menos de 
dos años a la fecha señalada, los medios de comunicación recogieron la historia. Los 
oficiales del gobierno expresaron su preocupación, los directores de la industria y de los 
negocios comprometieron grandes cantidades de dinero, y por Último, las advertencias horri- 
bles de catástrofe llegaron a la conciencia del público. El software, al igual que el ahora famoso 
error Y2K, podría fallar, y como resultado, detener el mundo como nosotros lo conocimos. 
Como vimos durante los últimos meses del año 1999, sin querer, no puedo dejar de pen- 
sar en el párrafo profético contenido en la primera página de la cuarta edición de este libro. 
Decía: 


El software de computadora se ha convertido en el alma mater. Es la máquina que conduce a la toma 
de decisiones comerciales. Sirve de base para la investigación científica moderna y de resolución de pro- 
blemas de ingeniería. Es el factor clave que diferencia los productos y servicios modernos. Está inmerso en 
sistemas de todo tipo: de transportes, médicos, de telecomunicaciones, militares, procesos industriales, entre- 
tenimientos, productos de oficina..., la lista es casi interminable. El software es casi ineludible en un mun- 
do moderno. A medida que nos adentremos en el siglo xx1, será el que nos conduzca a nuevos avances en 
todo, desde la educación elemental a la ingeniería genética. 


VISTAZO RÁPIDO 


¿Qué es? El software de computadora es ¿Por qué es importante? Porque ¿Cuál es el preducto obtenido?Des- 


el producto que diseñian y construyen 
los ingenieros del software. Esto abar- 
ca programas que se ejecutan dentro 
de una computadora de cualquier 
tamaño y arquitectura, documentos 


que comprenden formularios virtuales 
e impresos y datos que combinan 


números y texto y también incluyen 


representaciones de información de 
audio, vídeo e imágenes. 


¿Quién lo hace? Los ingenierosde soft- 


ware lo construyen, y virtualmente 
cualquier persona en el mundo indus- 
trialiiadolo utiliza bien directa oindi- 
rectamente, 


afecta muy de cerca a cualquier 
aspecto de nuestra vic a y está muy 
extendido en nuestro comercio, cuí- 
tura y en nuestras actividades coti- 
dianas. 


¿Cuáles son los pasos? Construir 


software de computacora como cons- 
truimos cualquier otro producto satis- 
factorio, aplicando un pioceso que 
conduce a un resultado de alta calidad 
que satisface las necesidades de la 
gente que usará el producto. Debes 
aplicar un enfoque de ingenieríade 
software. 


de el punto de vista deun ingeniero de 
software, el producto obtenidosonlos 
programas, documentos y los datos 
que configuran el software de compu- 
tadora. Pero desde elpunto de vista de 
los usuarios el producto obtenido es lo 
información resultante que hace de 


algún modo el mundo mejor a los 
tisuarios. : : 


¿Cómo puedo estar seguro de que 


lo he hecho correctamente? Lee 
el resto de.este libro, selecciona aque- 
llas ideas que son aplicables al soft- 


ware queconstruyes y aplícalas a tu 
trabajo. 


Cinco años después de que la cuarta edición de este libro fue escrita, el papel del software 
como «alma mater» ha llegado a ser más obvio.Un director de software de Intemet ha produ- 
cido su propia economía de 500 billones de Euros. En la euforia creada por la promesa de un 
paradigma económico nuevo, los inversores de Wall Street dieron a las pequeñas empresas 
«punto-com» estimaciones en billones de dólares antes de que éstas comenzasen a producir un 
dólar en ventas. Han surgido nuevas industrias dirigidas por software y las antiguas que no se 
han adaptado a esta nueva tendencia están ahora amenazadas de extinción. El gobierno de Esta- 
dos Unidos ha mantenido un contencioso frente a la mayor compañía de la industria del soft- 
ware, como lo mantuvo hace poco tiempo cuando se movilizó para detener las actividades 
monopolísticas en las industrias del acero y del aceite. 

El impacto del software en nuestra sociedad y en la cultura continúa siendo profundo. Al 
mismo tiempo que crece su importancia, la comunidad del software trata continuamente de 
desarrollar tecnologías que hagan más sencillo, rápido y menos costosa la construcción de pro- 
gramas de computadora de alta calidad. 

Este libro presenta un marco de trabajo que puede ser usado por aquellos que construyen 
software informático — aquellos que lo deben hacer bien—. La tecnología que comprende un 
proceso, un juego de métodos y un conjunto de herramientas se llama ingeniería del software. 
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INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRACTICO 


Hoy en día el software tiene un doble papel. Es un pro- 
ducto y, al mismo tiempo, el vehículo para entregarlo. 
Como producto, hace entrega de la potencia informáti- 
ca que incorpora el hardware informático o, más amplia- 
mente, una red de computadoras que es accesible por 
hardware local. Si reside dentro de un teléfono celular 
u opera dentro de una computadora central, el softwa- 
re es un transformador de información, produciendo, 
gestionando, adquiriendo, modificando, mostrando o 
transmitiendo información que puede ser tan simple 
como un solo bit, O tan complejo como una presenta- 
ción en multimedia. Como vehículo utilizado para hacer 
entrega del producto, el software actúa como la base de 
control de la computadora (sistemas operativos), la 
comunicación de información (redes) y la creación y 
control de otros programas (herramientas de software 
y entomos). 


pre 


Esoftware es tonto un producto, 
como el vehículo poro su entrego 


El papel del software informático ha sufrido un cam- 
bio significativo durante un periodo de tiempo superior 
a 50 años. Enormes mejoras en rendimiento del hard- 
ware, profundos cambios de arquitecturas informáticas, 
grandes aumentos de memoria y capacidad de almace- 
namiento y una gran variedad de opciones de entrada y 
salida han conducido a sistemas más sofisticados y más 
complejos basados en computadora. La sofisticación y 
la complejidad pueden producir resultados deslum- 
brantes cuando un sistema tiene éxito, pero también pue- 
den suponer grandes problemas para aquellos que deben 
construir sistemas complejos. 

Libros populares publicados durante los años 70 y 80 
proporcionan una visión histórica útil dentro de la per- 
cepción cambiante de las computadoras y del software, 
y de su impacto en nuestra cultura. Osborne [OSB79] 
hablaba de una «nueva revolución industrial», Toffler 
[TOF380] llamó a la llegada de componentes microelec- 
trónicos la «tercera ola del cambio» en la historia de la 
humanidad, y Naisbitt [NA182] predijo la transformación 
de la sociedad industrial a una «sociedad de informa- 
ción». Feigenbaum y McCorduck [FEI83] sugirieron que 
la información y el conocimiento (controladospor com- 
putadora) serían el foco de poder del siglo veintiuno, y 
Stoll [STO89] argumentó que la «comunidad electróni- 
ca» creada mediante redes y softwarees la clave para el 
intercambio de conocimiento alrededor del mundo. 

Al comienzo de los años 90, Toffler [TOF90] descri- 
bió un «cambio de poder» en el que las viejas estructu- 
ras de poder (gubernamentales,educativas, industriales, 
económicas y militares) se desintegrarían a medida que 


e en ha futuro, más allá delo que el ojo 
ede ver Tuve una visión del mundo 


las computadoras y el software nos llevaran a la «demo- 
cratización del conocimiento». A Yourdon [YOU92] le 
preocupaba que las compañíasen Estados Unidos pudie- 
ran perder su competitividad en empresas relativas al 
software y predijo «el declive y la caída del programa- 
dor americano». Hammer y Champy [HAM093] argu- 
mentaron que las tecnologías de información iban a 
desempeñar el papel principal en la «reingeniería de la 
compañía». A mediados de los años 90, la persistencia de 
las computadoras y del software generó una erupción de 
librospor «neo-Luddites» (porejemplo: Resisting the Vir- 
tual Life, editado por James Brook y lan Boal, y The Futu- 
re Does not Compute de Stephen Talbot). Estos autores 
critican enormemente la computadora, haciendo énfasis 
en preocupaciones legítimas pero ignorando los profun- 
dos beneficios que se han llevado a cabo [LEV95]. 


Al final de los años 90, Yourdon [YOU96] volvió a 
evaluar las perspectivas del software profesional y sugi- 
rió la «resurrección y elevación» del programador ame- 
ricano. A medida que internet creció en importancia, su 
cambio de pensamiento demostró ser correcto. Al final 
del siglo veinte, el enfoque cambió una vez más. Aquí 
tuvo lugar el impacto de la «bomba de relojería» Y2K 
(por ejemplo: [YOU98b], [DEJ98], [KAR99]). Aunque 
muchos vieron las predicciones de los críticos del Y2K 
como reacciones, sus populares lecturas devolvieron la 
difusión del software a sus vidas. Hoy en día, «la com- 
putación omnipresente»[NOR98] ha producido una gene- 
ración de aplicaciones de información que tienen 
conexión en banda ancha a la Web para proporcionar 
«una capa de conexión sobre nuestras casas, oficinas, y 
autopistas» [LEV99]. El papel del software continúa su 
expansión. 

El programador solitario de antaño ha sido reempla- 
zado por un equipo de especialistasdel software,cada uno 
centradoen una parte de la tecnologíarequerida para entre- 
garuna aplicación concreta. Y de este modo, las cuestio- 
nes que se preguntaba el programador solitario son las 
mismas cuestiones que nos preguntamos cuando cons- 
truimos sistemas modernos basados en computadoras: 
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Estadísticas globales de software 


CAPITULO 1 EL PRODUCTO Y EL PROCESO 


e ¿Por qué lleva tanto tiempo terminar los programas? 
e ¿Por qué son tan elevados los costes de desarrollo? 


e ¿Por qué no podemos encontrar todos los errores 
antes de entregar el software a nuestros clientes? 


e ¿Por qué nos resulta difícil constatar el progreso con- 
forme se desarrolla el software? 


En 1970, menos del uno por ciento de las personas 
podría haber descrito inteligentemente lo que significa- 
ba «software de computadora». Hoy, la mayoría de los 
profesionales y muchas personas en general piensan en 
su mayoría que comprenden el software. ¿Pero lo entien- 
den realmente? 


1.2.1. Características del software 


Para poder comprender lo que es el software (y con- 
secuentemente la ingeniería del software), es impor- 
tante examinar las características del software que lo 
diferencian de otras cosas que los hombres pueden 
construir. Cuando se construye hardware, el proceso 
creativo humano (análisis, diseño, construcción, prue- 
ba) se traduce finalmente en una forma física. Si cons- 
truimos una nueva computadora, nuestro boceto 
inicial, diagramas formales de diseño y prototipo de 
prueba, evolucionan hacia un producto físico (chips, 
tarjetas de circuitos impresos, fuentes de potencia, 
etc.). 

El software es un elemento del sistema que es 
lógico, en lugar de físico. Por tanto el software tie- 
ne unas características considerablemente distintas 
a las del hardware: 


Ave 


Esoftware se desarrolla, no se fabrica. 


1. El software se desarrolla, 
no sefabrica en un sentido clásico. 


Aunque existen similitudes entre el desarrollo del soft- 
ware y la construcción del hardware, ambas activida- 
des son fundamentalmente diferentes. En ambas 
actividades la buena calidad se adquiere mediante un 
buen diseño, pero la fase de construcción del hard- 
ware puede introducir problemas de calidad que no 
existen (o son fácilmente corregibles) en el software. 
Ambas actividades dependen de las personas, pero la 
relación entre las personas dedicadas y el trabajo rea- 
lizado es completamente diferente para el software 
(véase el Capítulo 7). Ambas actividades requieren 
la construcción de un «producto» pero los enfoques 
son diferentes. 


Los costes del software se encuentran en la ingeniería. 
Esto significaque los proyectos de software no se pueden 
gestionar como si fueran proyectos de fabricación. 


2. El software no se «estropea». 


La Figura 1.1 describe, para el hardware, la proporción 
de fallos como una función del tiempo. Esa relación, deno- 
minada frecuentemente «curva de bañera», indica que el 
hardware exhibe relativamente muchos fallos al princi- 
pio de su vida (estos fallos son atribuibles normalmente 
a defectos del diseño o de la fabricación); una vez corre- 
gidos los defectos, la tasa de fallos cae hasta un nivel esta- 
cionario (bastante bajo, con un poco de optimismo) donde 
permanece durante un cierto periodo de tiempo. Sin 
embargo, conforme pasa el tiempo, el hardware empie- 
za a desgastarse y la tasa de fallos se incrementa. 

El software no es susceptible a los males del entor- 
no que hacen que el hardware se estropee. Por tanto, en 
teoría, la curva de fallos para el software tendría la for- 
ma que muestra la Figura 1.2.Los defectos no detecta- 
dos haran que falle el programa durante las primeras 
etapas de su vida. Sin embargo, una vez que se corri- 
gen (suponiendo que no se introducen nuevos errores) 
la curva se aplana, como se muestra. La curva ideali- 
zada es una gran simplificación de los modelos reales 
de fallos del software (vease más información en el 
Capítulo 8). Sin embargo la implicación es clara, el soft- 
ware no se estropea. ¡Pero se deteriora! 


: CLA VE 


Bsoftware no se estropea, pero se deteriora. 


Mortalidad 
infantil 


Se estropea 


Í di e de fall s 


Tiempo 


FIGURA 1.1. Curva de fallos del hardware. 
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INGENIERÍA DEL SOFTWARE. UN ENFUQUE PKAUIICU 


Esto que parece una contradicción, puede compren- 
derse mejor considerando«la curva actual» mostrada en 
la Figura 1.2. Durante su vida, el software sufre cambios 
(mantenimiento). Conforme se hacen los cambios, es 
bastante probable que se introduzcan nuevos defectos, 
haciendo que la curva de fallos tenga picos como se ve 
en la Figura 1.2. Antes de que la curva pueda volver al 
estado estacionario original, se solicita otro cambio, 
haciendo que de nuevo se cree otro pico. Lentamente, el 
nivel mínimo de fallos comienza a crecer —el software 
se va deteriorando debido a los cambios —. 

Otro aspecto de ese deterioro ilustra la diferencia entre 
el hardware y el software. Cuando un componente de 
hardware se estropea se sustituyepor una pieza de repues- 
to. No hay piezas de repuesto para el software. Cada fallo 
en el software indica un error en el diseño o en el proce- 
so mediante el que se tradujo el diseño a código máqui- 
na ejecutable. Por tanto, el mantenimiento del software 
tiene una complejidad considerablemente mayor que la 
del mantenimiento del hardware. 


3. Aunque la industria tiende a ensamblar componen- 
tes, la mayoría del software se construye a medida. 


Consideremos la forma en la que se diseña y se cons- 

truye el hardware de control para un producto basa- 
do en computadora. El ingeniero de diseño construye 
un sencillo esquema de la circuitería digital, hace 
algún análisis fundamental para asegurar que se con- 
sigue la función adecuada y va al armario donde se 
encuentran los catálogos de componentes digitales. 
Después de seleccionar cada componente, puede soli- 
citarse la compra. 


Incremento 
del índice de fallos 
por efectos laterales 


N 


cambio 


Curva real 


Índice de fallos 


Curva idealizada 


Tiempo 


FIGURA 1.2. Curvas de fallos real e idealizada del software. 


e 
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los mébobs de ingeniería de software se esfuerzan 
para reducirla megniua de los pios y la inclinación 
de la curva (Fig. 1.2). 


A medida que la disciplina del software evoluciona, se 
crea un grupo de componentesde diseño estándar. Torni- 
llos estándar y circuitosintegradospreparados para la ven- 
ta son solamente los dos mil coinponentes estándar que 
utilizan ingenieros mecánicos y eléctricos cuando dise- 
ñan nuevos sistemas. Los componentes reutilizables se 
han creado para que el ingeniero pueda concentrarse en 
elementos verdaderamente innovadores de un diseño, por 
ejemplo, las partes del diseño que representan algo nue- 
vo. En el mundo del hardware, la reutilización de com- 
ponentes es una parte natural del proceso de ingeniería. 
En el mundo del softwarees algo que sólo ha comenza- 
do a lograrse en una escala amplia. 

El componente de software debería diseñarse e 
implementarse para que pueda volver a ser reutiliza- 
do en muchos programas diferentes. En los años 60, 
se construyeron bibliotecas de subrutinas científicas 
reutilizables en una amplia serie de aplicaciones cien- 
tíficas y de ingeniería. Esas bibliotecas de subrutinas 
reutilizaban de forma efectiva algoritmos bien defi- 
nidos, pero tenían un dominio de aplicación limita- 
do. Hoy en día, hemos extendido nuestra visión de 
reutilización para abarcar no sólo los algorítmos, sino 
también estructuras de datos. Los componentes reu- 
tilizables modernos encapsulan tanto datos como pro- 
cesos que se aplican a los datos, permitiendo al 
ingeniero del software crear nuevas aplicaciones a 
partir de las partes reutilizables. Por ejemplo, las 
interfaces gráficas de usuario de hoy en día se cons- 
truyen frecuentemente a partir de componentes reu- 
tilizables que permiten la creación de ventanas 
gráficas, de menús despleglables y de una amplia 
variedad de mecanismos de interacción. 


C VE 
La mayak del softwore sigue constuyéndose a medida. 


1.2.2. Aplicaciones del software 


El software puede aplicarse en cualquier situación en la 
que se haya definido previamente un conjunto especí- 
fico de pasos procedimentales (es decir, un algoritmo) 
(excepciones notables a esta regla son el software de 
los sistemas expertos y de redes neuronales). El conte- 
nido y el determinismo de la información son factores 
importantes a considerar para determinar la naturaleza 
de una aplicación de software. El contenido se refiere 
al significado y a la forma de la información de entra- 
da y salida. Por ejemplo, muchas aplicaciones banca- 
rias usan unos datos de entrada muy estructurados (una 
base de datos) y producen «informes» con determina- 
dos formatos. El software que controla una máquina 
automática (por ejemplo: un control numérico) acepta 
elementos de datos discretos con una estructura limita- 
da y produce órdenes concretas para la máquina en rápi- 
da sucesión. 
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la revolución del software se foto en el Capítulo 13. 
Lo ingenieríade software basada en componentes 
se presento en el Capítulo 27, 


El determinismo de la información se refiere a la pre- 
decibilidad del orden y del tiempo de llegada de los 
datos. Un programa de análisis de ingeniería acepta datos 
que están en un orden predefinido, ejecuta el algorit- 
mo(s) de análisis sin interrupción y produce los datos 
resultantes en un informe o formato gráfico. Se dice que 
tales aplicaciones son determinadas. Un sistema opera- 
tivo multiusuario, por otra parte, acepta entradas que 
tienen un contenido variado y que se producen en ins- 
tantes arbitrarios, ejecuta algoritmos que pueden ser 
interrumpidos por condiciones externas y produce una 
salida que depende de una función del entorno y del 
tiempo. Las aplicaciones con estas características se dice 
que son indeterminadas. 

Algunas veces es difícil establecer categorías gené- 
ricas para las aplicaciones del software que sean sig- 
nificativas. Conforme aumenta la complejidad del 
software, es más difícil establecer compartimentos 
nítidamente separados. Las siguientes áreas del soft- 
ware indican la amplitud de las aplicaciones poten- 
ciales: 


Software de sistemas. El software de sistemas es 
un conjunto de programas que han sido escritos para 
servir a otros programas. Algunos programas de siste- 
mas (por ejemplo: compiladores, editores y utilidades 
de gestión de archivos) procesan estructuras de infor- 
mación complejas pero determinadas. Otras aplicacio- 
nes de sistemas (por ejemplo: ciertos componentes del 
sistema operativo, utilidades de manejo de periféricos, 
procesadores de telecomunicaciones)procesan datos en 
gran medida indeterminados. En cualquier caso, el área 
del software de sistemas se caracteriza por una fuerte 
interacción con el hardware de la computadora; una gran 
utilización por múltiples usuarios; una operación con- 
currente que requiere una planificación, una comparti- 
ción de recursos y una sofisticada gestión de procesos; 
unas estructuras de datos complejas y múltiples inter- 
faces externas. 


Software de tiempo real. El software que coor- 
dina/analiza/controla sucesos del mundo real conforme 
ocurren, se denomina de tiempo real. Entre los elemen- 
tos del software de tiempo real se incluyen: un compo- 
nente de adquisición de datos que recolecta y da formato 
a la información recibida del entorno externo, un com- 
ponente de análisis que transforma la información según 
lorequiera la aplicación, un componente de control/salida 
que responda al entorno externo, y un componente de 
monitorización que coordina todos los demás compo- 
nentes, de forma que pueda mantenerse la repuesta en 
tiempo real (típicamenteen el rango de un milisegundo 
a un segundo). 


CAPITULO 1 ELPRODUCTO Y EL PROCESO 


Software de gestión. El proceso de la información 
comercial constituye la mayor de las áreas de aplica- 
ción del software. Los «sistemas» discretos (por ejem- 
plo: nóminas, cuentas de haberes-débitos, inventarios, 
etc.) han evolucionado hacia el software de sistemas de 
información de gestión (SIG) que accede a una O más 
bases de datos que contienen información comercial. 
Las aplicaciones en esta área reestructuran los datos 
existentes para facilitar las operaciones comerciales O 
gestionar la toma de decisiones. Además de las tareas 
convencionales de procesamientos de datos, las aplica- 
ciones de software de gestión también realizan cálculo 
interactivo (por ejemplo: el procesamiento de transac- 
ciones en puntos de ventas). 


Software de ingeniería y científico. El software 
de ingeniería y científico está caracterizado por los 
algoritmos de «manejo de números». Las aplicacio- 
nes van desde la astronomía a la vulcanología, desde 
el análisis de la presión de los automotores a la diná- 
mica orbital de las lanzaderas espaciales y desde la 
biología molecular a la fabricación automática. Sin 
embargo, las nuevas aplicaciones del área de inge- 
niería/ciencia se han alejado de los algoritmos con- 
vencionales numéricos. El diseño asistido por 
computadora (del inglés CAD), la simulación de sis- 
temas y otras aplicaciones interactivas, han comen- 
zado a coger características del software de tiempo 
real e incluso del software de sistemas. 


Software empotrado. Los productos inteligentes se 
han convertido en algo común en casi todos los merca- 
dos de consumo e industriales. El software empotrado 
reside en memoria de sólo lectura y se utiliza para con- 
trolar productos y sistemas de los mercados industria- 
les y de consumo. El software empotrado puede ejecutar 
funciones muy limitadas y curiosas (por ejemplo: el con- 
trol de las teclas de un horno de microondas) o sumi- 
nistrar una función significativa y con capacidad de 
control (por ejemplo: funciones digitales en un auto- 
móvil, tales como control de la gasolina, indicadores en 
el salpicadero, sistemas de frenado, etc.). 


Referencia Web 


Se puede encontrar una de las mayores bibliotecas 
de shareware /freeware en www.shareware.com 


Software de computadoras personales. El mercado 
del software de computadoras personales ha germinado 
en las pasadas dos décadas. El procesamiento de tex- 
tos, las hojas de cálculo, los gráficos por computadora, 
multimedia, entretenimientos, gestión de bases de datos, 
aplicaciones financieras, de negocios y personales y 
redes o acceso a bases de datos externas son algunas de 
los cientos de aplicaciones. 
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Software basado en Web, Las páginas Web busca- 
das por un explorador son software que incorpora ins- 
trucciones ejecutables (por ejemplo, CGI, HTML, Perl, 
O Java), y datos (por ejemplo, hipertexto y una varie- 
dad de formatos de audio y visuales). En esencia, la red 
viene a ser una gran computadora que proporciona un 
recurso software casi ilimitado que puede ser accedido 
por cualquiera con un modem. 


Softwarede inteligencia artificial.El software de inte- 
ligencia artificial (1A) hace uso de algoritmos no numéri- 
cos para resolver problemas complejospara los queno son 
adecuadosel cálculo o el análisisdirecto. Los sistemas exper- 
tos, también llamados sistemasbasados en el conocimiento, 
reconocimiento de patrones (imágenes y voz), redes neu- 
ronales artificiales, prueba de teoremas, y los juegos son 
representativos de las aplicaciones de esta categoría. 


Muchos observadores de la industria (incluyendo este 
autor) han caracterizado los problemas asociados con el 
desarrollo del software como una «crisis». Más de unos 


cuantos libros (por ejemplo: [GLA97], [FLO97], 
[YOU98a]) han recogido el impacto de algunos de los 
fallos mas importantes que ocurrieron durante la déca- 
da pasada. No obstante, los mayores éxitos conseguidos 
por la industria del software han llevado a preguntarse 
si el término (crisis del software) es aún apropiado. 
Robert Glass, autor de varios libros sobre fallos del soft- 
ware, representa a aquellos que han sufrido un cambio 
de pensamiento. Expone [GLA98]: «Puedo ver en mis 
ensayos históricos de fallos y en mis informes de excep- 
ción, fallos importantesen medio de muchos éxitos, una 
copa que está [ahora] prácticamente llena.» 


de los expertos están de acuerdo 

onera más probable para que el mundo 
es por accidente. Ahí es donde nosotros 
oros profesionales de la informática, 
occidentes. 


La palabra crisis se define en el diccionario Webster 
como «un punto decisivo en el curso de algo, momento, 
etapa o evento decisivo o crucial». Sin embargo, en térmi- 
nos de calidad del softwaretotal y de velocidad con la cual 
son desarrolladoslos productos y los sistemas basados en 


computadoras, no ha habido ningún «puntocrucial», nin- 
gún «momento decisivo», solamente un lento cambio evo- 
lutivo, puntualizado por cambios tecnológicos explosivos 
en las disciplinasrelacionadas con el software. 

Cualquiera que busque la palabra crisis en el dic- 
cionario encontrará otra definición: «el punto decisivo 
en el curso de una enfermedad, cuando se ve más claro 
si el paciente vivirá o morirá». Esta definición puede 
darnos una pista sobre la verdadera naturaleza de los 
problemas que han acosado el desarrollo del software. 

Lo que realmente tenemos es una aflicción crónica. 
La palabra aflicción se define como «algoque causa pena 
O desastre». Pero la clave de nuestro argumentoes la defi- 
nición del adjetivo crónica: «muy duradero o que reapa- 
rece con frecuencia continuando indefinidamente». Es 
bastante más preciso describir los problemas que hemos 
estado aguantando en el negocio del software como una 
aflicción crónica, en vez de como una crisis. 

Sin tener en cuenta como lo llamemos, el conjunto 
de problemas encontrados en el desarrollo del software 
de computadoras no se limitan al software que «no fun- 
ciona correctamente». Es más, el mal abarca los pro- 
blemas asociados a cómo desarrollar software, cómo 
mantener el volumen cada vez mayor de software exis- 
tente y cómo poder esperar mantenemos al corriente de 
la demanda creciente de software. 

Vivimos con esta aflicción desde este día —de hecho, 
la industria prospera a pesar de ello—. Y así, las cosas 
podrán ser mejores si podemos encontrar y aplicar un 
remedio. 


Muchas de las causas de la crisis del software se pue- 
den encontrar en una mitología que surge durante los 
primeros años del desarrollo del software. A diferencia 
de los mitos antiguos, que a menudo proporcionaban a 
los hombres lecciones dignas de tener en cuenta, los 
mitos del software propagaron información errónea y 


confusión. Los mitos del software tienen varios atribu- 


tos que los hacen insidiosos: por ejemplo, aparecieron 
como declaraciones razonables de hechos (algunas veces 
conteniendo elementos verdaderos), tuvieron un senti- 
do intuitivo y frecuentemente fueron promulgados por 
expertos que «estaban al día». 


1 Esta terminología fue sugerida por el profesor Daniel Tiechrow de la 
Universidad de Michigan en una conferencia impartida en Ginebra, 
Suiza, Abril, 1989. 
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Mitos de gestión. Los gestores con responsabilidad 
sobre el software, como los gestores en la mayoría de 
las disciplinas, están normalmente bajo la presión de 
cumplir los presupuestos, hacer que no se retrase el pro- 
yecto y mejorar la calidad. Igual que se agarra al vacío 
una persona que se ahoga, un gestor de software se aga- 
rra frecuentemente a un mito del software, aunque tal 
creencia sólo disminuya la presión temporalmente. 


Mito. Tenemos ya un libro que está lleno de estánda- 
res y procedimientos para construir software, ¿no le pro- 
porciona ya a mi gente todo lo que necesita saber? 


Realidad. Está muy bien que el libro exista, pero 
jse usa?.¿conocen los trabajadores su existencia?, 
jrefleja las prácticas modernas de desarrollo de soft- 
ware?, ¿es completo?, ¿está diseñado para mejorar el 
tiempo de entrega mientras mantiene un enfoque de 
calidad? En muchos casos, la respuesta a todas estas 
preguntas es «no», 


estándares significativos, 
industria como lo del software 
er de los costumbres. 


Mito. Mi gente dispone de las herramientas de desa- 
rrollo de software más avanzadas, después de todo, les 
compramos las computadoras más modernas. 


Realidad. Se necesita mucho más que el último 
modelo de computadora grande o de PC para hacer desa- 
rrollo de software de gran calidad. Las herramientas de 
ingeniería del software asistida por computadora 
(CASE) son más importantes que el hardware para con- 
seguir buena calidad y productividad, aunque la mayo- 
ría de los desarrolladores del software todavía no las 
utilicen eficazmente. 


Mito. Si fallamos en la planificación, podemos añadir 
más programadores y adelantar el tiempo perdido (el lla- 
mado algunas veces «conceptode la horda Mongoliana»). 


Realidad. El desarrollo de software no es un proce- 
so mecánico como la fabricación. En palabras de Bro- 
oks [BRO75]: <«...añadir gente a un proyecto de software 
retrasado lo retrasa aún más». Al principio, esta declara- 
ción puede parecer un contrasentido. Sin embargo, cuan- 
do se añaden nuevas personas, la necesidad de aprender y 
comunicarsecon el equipo puede y hace que se reduzca la 
cantidad de tiempo gastado en el desarrollo productivo. 
Puede añadirse gente, pero sólo de una manera planifica- 
da y bien coordinada. 


Referencia Web 


la red de gestión de proyectos de software 
en www.spmn.com puede ayudarle 
a desmitificar estos y otros mitos. 
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Mitos del Cliente. Un cliente que solicita una apli- 
cación de software puede ser una persona del despacho 
de al lado, un grupo técnico de la sala de abajo, el depar- 
tamento de ventas o una compañía exterior que solicita 
un software bajo contrato. En muchos casos, el cliente 
cree en los mitos que existen sobre el software, debido a 
que los gestores y desarrolladoresdel software hacen muy 
poco para corregir la mala información. Los mitos con- 
ducen a que el cliente se cree una falsa expectativa y, final- 
mente, quede insatisfechocon el que desarrolla el software. 


Mito. Una declaración general de los objetivos es sufi- 
ciente para comenzar a escribir los programas —pode- 
mos dar los detalles más adelante —. 


Realidad. Una mala definición inicial es la principal 
causa del trabajo baldío en software. Es esencial una des- 
cripción formal y detallada del ámbitode la información, 
funciones, comportamiento, rendimiento, interfaces, liga- 
duras del diseño y criterios de validación. Estas caracte- 
rísticas pueden determinarse sólo después de una 
exhaustiva comunicación entre el cliente y el analista. 


Mito. Los requisitos del proyecto cambian conti- 
nuamente, pero los cambios pueden acomodarse fácil- 
mente, ya que el software es flexible. 


l a gestión y control de cambio está tratada 
con detalle en el Capítulo 9 


! 60-100x 


Coste del cambio 


Después 
de la entrega 


Definición Desarrollo 


FIGURA 1.3. El impacto del cambio. 


Realidad. Es verdad que los requisitos del softwa- 
re cambian, pero el impacto del cambio varía según el 
momento en que se introduzca. La Figura 1.3 ilustra el 
impacto de los cambios. Si se pone cuidado al dar la 
definición inicial, los cambios solicitados al principio 
pueden acomodarse fácilmente. El cliente puede revi- 
sar los requisitos y recomendar las modificaciones con 
relativamente poco impacto en el coste. Cuando los cam- 
bios se solicitan durante el diseño del software, el impac- 
to en el coste crece rápidamente. Ya se han acordado los 
recursos a utilizar y se ha establecido un marco de tra- 
bajo del diseño. Los cambios pueden producir trastor- 
nos que requieran recursos adicionales e importantes 
modificaciones del diseño; es decir, coste adicional. Los 
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cambios en la función, rendimiento, interfaces u otras 
características, durante la implementación (codificación 
y prueba) pueden tener un impacto importante sobre el 
coste. Cuando se solicitan al final de un proyecto, los 
cambios pueden producir un orden de magnitud más 
caro que el mismo cambio pedido al principio. 


Mitos de los desarrolladores. Los mitos en los que 
aún creen muchos desarrolladores se han ido fomen- 
tando durante 50 años de cultura informática. Durante 
los primeros días del desarrollo del software, la pro- 
gramación se veía como un arte. Las viejas formas y 
actitudes tardan en morir. 


Mito. Una vez que escribimos el programa y hace- 
mos que funcione, nuestro trabajo ha terminado. 


Realidad. Alguien dijo una vez: «cuanto más pronto 
se comience a escribir código, más se tardará en termi- 
narlo». Los datos industriales [LIE80, JON91, PUT97] 
indican que entre el 60 y el 80 por ciento de todo el 
esfuerzo dedicado a un programa se realizará después 
de que se le haya entregado al cliente por primera vez. 


Cons) 


Trabaja muy duro poro entender lo que tienes quehacer 
antes de empezar. No serías copoz de desarrollar codo 
detalle; por más quesepas, tomo el menor riesgo. 


Mito. Hasta que no tengo el programa «ejecutándo- 
se», realmente no tengo forma de comprobar su calidad. 


Realidad. Desde el principio del proyecto se puede 
aplicar uno de los mecanismos más efectivos para garan- 
tizar la calidad del software: la revisión técnicaformal. 
La revisión del software (descrito en el Capítulo 8) es 
un «filtro de calidad» que se ha comprobado que es más 
efectivo que la prueba, para encontrar ciertas clases de 
defectos en el software. 


Mito. Lo único que se entrega al terminar el pro- 
yecto es el programa funcionando. 


Realidad. Un programa que funcionaes sólo una par- 
te de una configuración del software que incluye muchos 
elementos. La documentación proporciona el funda- 
mento para un buen desarrollo y, lo que es más impor- 
tante, proporciona guías para la tarea de mantenimiento 
del software. 


Muchos profesionales del software reconocen la 
falacia de los mitos descritos anteriormente. Lamen- 
tablemente, las actitudes y métodos habituales fomen- 
tan una pobre gestión y malas prácticas técnicas, 
incluso cuando la realidad dicta un método mejor. El 
reconocimiento de las realidades del software es el 
primer paso hacia la formulación de soluciones prác- 
ticas para su desarrollo. 


El software se ha convertido en el elemento clave de 
la evolución de los sistemas y productos informáticos. 
En los pasados 50 años, el software ha pasado de ser 
una resolución de problemas especializada y una herra- 
mienta de análisis de información, a ser una industria 
por sí misma. Pero la temprana cultura e historia de la 
«programación» ha creado un conjunto de problemas 
que persisten todavía hoy. El software se ha converti- 
do en un factor que limita la evolución de los sistemas 
informáticos. El software se compone de programas, 
datos y documentos. Cada uno de estos elementos com- 


ponen una configuración que se crea como parte del 
proceso de la ingeniería del software. El intento de la 
ingeniería del software es proporcionar un marco de 
trabajo para construir software con mayor calidad. 


Cons 


Cuando te pones o pensar, no encuentras tiempoporo la 
disciplino de lo ingeniería delsoftwore, y te preguntas: 
«¿Tendré tiempo para poder hacerlo?» 


[BRO75] Brooks, F., The Mytical Man-Month, Addison-Wes- 
ley, 1975. 
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[FLO97] Flowers, S., Software Failure, Management Fai- 
lure-Amaicing Stories and Cautionary Tails, Wiley, 
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1.1. El software es la característica que diferencia a muchos 
productos y sistemas informáticos. Dé ejemplos de dos o tres 
productos y de, al menos, un sistema en el que el software, no 
el hardware, sea el elemento diferenciador. 


1.2. En losaños cincuenta y sesentala programación de com- 
putadoras era un arte aprendido en un entorno básicamente 
experimental. ¿Cómo ha afectado esto a las prácticas de desa- 
rrollo del software hoy? 


1.3. Muchos autores han tratado el impacto de la «era de la 
información».Dé varios ejemplos (positivos y negativos) que 
indiquen el impacto del software en nuestra sociedad. Repa- 
se algunasreferencias de la Sección 1.1 previas a 1990e indi- 
que dónde las predicciones del autor fueron correctas y dónde 
no lo fueron. 


1.4. Seleccione una aplicación específica e indique: (a) la 
categoría de la aplicación de software (Sección 1.2.2) en la 
que encaje; (b) el contenido de los datos asociados con la apli- 
cación; (c) la información determinada de la aplicación. 


1.5. A medida que el software se difunde más, los riesgos para 
el público (debido a programas defectuosos) se convierten en una 
preocupación cada vez más significativa. Desarrolle un escena- 
rio realista del juicio final (distinto a Y2K) en donde el fallo de 
computadorapodría hacer un gran daño (económicoo humano). 


1.6. Lea detenidamente el grupo de noticias de Internet 
comp.risk y prepare un resumen de riesgos para las personas 
con las que se hayan tratado Últimamente. Código alternati- 
vo: Software Engineering Notes publicado por la ACM. 


1.7. Escriba un papel que resuma las ventajas recientes en 
una de las áreas de aplicaciones de software principales. Entre 
las selecciones potenciales se incluyen: aplicaciones avanza- 
das basadas en Web, realidad virtual, redes neuronales artifi- 
ciales, interfaces humanas avanzadas y agentes inteligentes. 


1.8. Los mitos destacados en la Sección 1.4 se están vinien- 
do abajo lentamente a medida que pasan los años. Pero otros 
se están haciendo un lugar. Intente añadir un mito o dos mitos 
«nuevos» a cada categoría. 


Literalmente existen miles de libros escritos sobre software 


de computadora. La gran mayoría tratan los lenguajes de pro- 
gramacióno aplicaciones de software, y sólo unos pocos tra- 
tan el software en sí. Pressman y Herron (Software Sock, 
Dorset House, 1991)presentaron una discusión (dirigida ano 
profesionales) acerca del software y del modo en que lo cons- 
truyen los profesionales. 

El libro, éxito de ventas, de Negroponte (Being Digital, 
Alfred A. Knopf, Inc., 1995) proporciona una visión de las 
computadoras y de su impacto global en el siglo xx1, Los 
libros de Norman [NOR98] y Bergman (Information 
Appliances £ Beyond, Academic Pres/Morgan Kauffman, 
2000) sugieren que el impacto extendido del PC declinará 
al mismo tiempo que las aplicaciones de información y 
la difusión de la programación conecten a todos en el mun- 
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do industrializado y casi todas las aplicaciones a la nueva 
infraestructura de Internet. 

Minasi (The Software Conspiracy: Why Software Com- 
panies Put Out Faulty Products, How They Can Hurt You, 
and What You Can Do, McGraw-Hill, 2000) argumentó que 
el «azote moderno» de los errores del software puede elimi- 
narse y sugiere formas para hacerlo. DeMarco (Why Does 
Software Cost So Much?, Dorset House, 1995) ha producido 
una colección de ensayos divertidos e interesantes sobre el 
software y el proceso a través del cual se desarrolla. 

En Intemet están disponibles una gran variedad de fuen- 
tes de información relacionadas con temas de gestión y de 
software. Se puede encontrar una lista actualizada con refe- 
rencias a sitios (páginas) web relevantes en http://www.press- 
man5.com. 
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CAPÍTULO 


EL PROCESO 


OWARD Baetjer, Jr. [BAE98], en un libro fascinante que proporciona un punto de 
vista economicista del software y de la ingeniería del software, comenta sobre el 
proceso: 


Como el software, al igual que el capital, es el conocimiento incorporado, y puesto que el conocimiento 
está inicialmente disperso, el desarrollo del software implícito, latente e incompleto en gran medida, es un 
proceso social de aprendizaje. El proceso es un diálogo en el que se reúne el conocimiento y se incluye en 
el software para convertirse en software. El proceso proporciona una interacción entre los usuarios y los 
diseñadores, entre los usuarios y las herramientas de desarrollo, y entre los diseñadores y las herramien- 
tas de desarrollo [tecnología]. Es un proceso interactivo donde la herramienta de desarrollo se usa como 
medio de comunicación, con cada iteración del diálogo se obtiene mayor conocimiento de las personas 
involucradas. 


Realmente, construir software de computadora es un proceso de aprendizaje iterativo, y el 
resultado, algo que Baetjer podría llamar «capital del software», es el conjunto del software 
reunido. denurado y organizado mientras se desarrolla el proceso. 


VISTAZO RÁPIDO 


¿Qué es? Cuando trabaja para construir ¿Por qué es importante? Porque pro- software, los productos obtenidos son 


un producto o un sistema, es impor- 
tante seguir una serie de pasos pre- 
decibles —un mapa de carreteras que 
le ayude a obtener el resultado opor- 
tuno de calidad —. El mapa de carre- 
teras aseguires llamado «proceso del 
softwate.. 


¿Quién lo hace? Los ingenieros de soft- 


ware y sus gestores adaptan el proce- 
so a sus necesidades y entonces lo 
siguen. Además las personas que han 
solicitado el software tienen un papel 


porciona estabilidad, control y organi- 
zación a una actividad que puede, si 
no se controla, volverse caótica. 


¿Cuáles sonlos pasos? A un nivel deta- 


llado, el proceso que adoptemos 
depende del software que estamos 
construyendo. Un proceso puede ser 
apropiado para crear software de un 
sistema de aviación, mientras que un 
proceso diferente por completo puede 
ser adecuado para la creación de un 
sitio web. 


programas, documentos y datos que se 
producen como consecuencia de las 
actividades de ingeniería del software 
definidas por el proceso. 


¿Cómo puedo estar seguro de que 


lo he hecho correctamente? Hay 
una cantidad de mecanismos de eva- 
luacion del proceso del software que 
permiten a las organizaciones deter- 
minar la «madurez» de su proceso del 
software. Sinembargo, la calidad, opor- 
tunidad y viabilidad a largo plazo del 


producto que está construyendo son los 
mejoresindicadores de la eficiencia del 
proceso que estamos utilizando. 


a desempeñar en el proceso del soft- ¿Cuál es el producto obtenido? Des- 


ware. de el punto de vista de un ingeniero de 


Pero, ¿qué es exactamenteel proceso del software desde un punto de vista técnico? Dentro del con- 
texto de este libro, definimos un proceso de software como un marco de trabajo de las tareas que se 
requieren para construir software de alta calidad. ¿Es «proceso» sinónimo de ingeniería del softwa- 
re? La respuesta es «sí» y «no». Un proceso de software define el enfoque que se toma cuando el soft- 
ware es tratado por la ingeniería. Pero la ingeniería del software también comprende las tecnologías 
que tiene el proceso — métodos técnicos y herramientas automatizadas —. 

Aún más importante es que la ingeniería del software la realizan personas creativas, con conoci- 
miento, que deberían trabajar dentro de un proceso del software definido y avanzado que es apropia- 
do para los productos que construyen y para las demandas de su mercado. La intención de este capítulo 
es proporcionar un estudio del estado actual del proceso del software y puntualizar sobre el estudio 
detallado de los temas de gestión y técnicos presentados en este libro. 
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INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRÁCTICO 


Aunque cientos de autores han desarrollado definicio- 
nes personales de la ingeniería del software, una defi- 
nición propuesta por Fritz Bauer [NAU69] en una 
conferencia de gran influencia sobre estos temas va a 
servir como base de estudio: 


noo una porte del 
lería es un verbo, una polobra 
Jo de enfocar el problema. 


[La ingeniería del software] es el establecimiento y uso de prin- 
cipios robustos de la ingeniería a fin de obtener económicamente 
software que sea fiable y que funcione eficientementesobre máqui- 
nas reales. 


Casi todos los lectores tendrán la tentación de 
seguir esta definición. No dice mucho sobre los aspec- 
tos técnicos de la calidad del software; no se enfren- 
ta directamente con la necesidad de la satisfacción del 
cliente o de la entrega oportuna del producto; omite 
la mención de la importancia de mediciones y métri- 
cas; tampoco expresa la importancia de un proceso 
avanzado. Y sin embargo, la definición de Bauer nos 
proporciona una línea base. ¿Cuáles son los «princi- 
pios robustos de la ingeniería» aplicables al desarro- 
llo de software de computadora? ¿Cómo construimos 
el software «económicamente» para que sea «fiable»? 
¿Qué se necesita para crear programas de computa- 
dora que funcionen «eficientemente» no en una máqui- 
na si no en diferentes «máquinas reales»? Éstas son 
cuestiones que siguen siendo un reto para los inge- 
nieros del software. 


¡ ¿Cómo definimos la 
Ingeniería del software? 


El IEEE [IEE93] ha desarrollado una definición más 
completa: 


Ingeniería del software: (1) La aplicación de un enfoque sis- 
temático, disciplinado y cuantificablehacia el desarrollo, opera- 
ción y mantenimiento del software; es decir, la aplicación de 
ingeniería al software. (2) El estudio de enfoques como en (1). 


2.1.1. Proceso, métodos y herramientas 


La Ingeniería del software es un tecnología multica- 
pa. Como muestra la Figura 2.1, cualquier enfoque de 
ingeniería (incluida ingeniería del software) debe apo- 
yarse sobre un compromiso de organización de cali- 
dad. 
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Un enfoque de calidad 


FIGURA 2.1. Capas de la ingeniería del software. 


El fundamento de la ingeniería del software es la 
capa de proceso. El proceso de la ingeniería del soft- 
ware es la unión que mantiene juntas las capas de tec- 
nología y que permite un desarrollo racional y oportuno 
de la ingeniería del software. El proceso define un mar- 
co de trabajo para un conjunto de Úreas clave de pro- 
ceso (ACPs) [PAU93] que se deben establecer para la 
entrega efectiva de la tecnología de la ingeniería del 
software. Las áreas claves del proceso forman la base 
del control de gestión de proyectos del software y esta- 
blecen el contexto en el que se aplican los métodos téc- 
nicos, se obtienen productos del trabajo (modelos, 
documentos, datos, informes, formularios, etc.), se esta- 
blecen hitos, se asegura la calidad y el cambio se ges- 
tiona adecuadamente. 

Los métodos de la ingeniería del software indican 
«cómo» construir técnicamente el software. Los méto- 
dos abarcan una gran gama de tareas que incluyen aná- 
lisis de requisitos, diseño, construcción de programas, 
pruebas y mantenimiento. Los métodos de la ingeniería 
del software dependen de un conjuntode principios bási- 
cos que gobiernan cada área de la tecnología e incluyen 
actividades de modelado y otras técnicas descriptivas. 


Y] 


SS 
CLAVE 


la Ingeriería de software comprende un proceso, 
mébcbs técrcos y de gesión, y herramientas. 


Las herramientas de la Ingeniería del software pro- 
porcionan un enfoque automático o semi-automáticopara 
el proceso y para los métodos. Cuando se integran herra- 
mientas para que la información creada por una herra- 
mienta la pueda utilizar otra, se establece un sistema de 
soporte para el desarrollo del software llamado ingenie- 
ría del software asistida por computadora (CASE). 


2.1.2. Una visión general de la ingeniería del 
software 


La ingeniería es el análisis, diseño, construcción, verl- 
ficación y gestión de entidades técnicas (o sociales). 
Con independencia de la entidad a la que se va a apli- 
car ingeniería, se deben cuestionar y responder las 
siguientes preguntas: 
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» ¿Cuál es el problema a resolver? 


+ ¿Cuáles son las características de la entidad que se 
utiliza para resolver el problema? 


+ ¿Cómo se realizará la entidad (y la solución)? 
+ ¿Cómo se construirá la entidad? 


» ¿Qué enfoque se va a utilizar para no contemplar los 
errores que se cometieron en el diseño y en la cons- 
trucción de la entidad? 


+ ¿Cómo se apoyará la entidad cuando usuarios soli- 
citen correcciones, adaptaciones y mejoras de la enti- 
dad? 


Referencia 


Crosstalk es un periódico que proporciona consejos y 
comentarios prócticos de ingeniería del software. Estón 
disponibles temas relacionados directamente en: 
www.stc.hilLaf.mil 


A lo largo de este libro, nos vamos a centrar en 
una sola entidad —el software de computadora— . 
Para construir la ingeniería del software adecuada- 
mente, se debe definir un proceso de desarrollo de 
software. En esta sección se consideran las caracte- 
rísticas genéricas del proceso de software. Más ade- 
lante, en este mismo capítulo, se tratarán modelos 
específicos de procesos. 

El trabajo que se asocia a la ingeniería del software 
se puede dividir en tres fases genéricas, con indepen- 
dencia del área de aplicación, tamaño o complejidad del 
proyecto. Cada fase se encuentra con una O varias cues- 
tiones de las destacadas anteriormente. 

La fase de definición se centra sobre el qué. Es decir, 
durante la definición, el que desarrolla el software inten- 
ta identificar qué información ha de ser procesada, qué 
función y rendimiento se desea, qué comportamiento 
del sistema, qué interfaces van a ser establecidas, qué 
restricciones de diseño existen, y qué criterios de vali- 
dación se necesitan para definir un sistema correcto. Por 
tanto, han de identificarse los requisitos clave del siste- 
ma y del software. Aunque los métodos aplicados duran- 
te la fase de definición variarán dependiendo del 
paradigma de ingeniería del software (o combinación 
de paradigmas) que se aplique, de alguna manera ten- 
drán lugar tres tareas principales: ingeniería de sistemas 
o de información (Capítulo 10), planificación del pro- 
yecto del software (Capítulos 3, 5, 6 y 7) y análisis de 
los requisitos (Capítulos 11,12 y 21). 


» 
La 
E software se crea aplicando tres fases distintas que se 
centran en la definición, desarrollo y mantenimiento. 
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Lafase de desarrollo se centra en el cómo. Es decir, 
durante el desarrollo un ingeniero del software intenta 
definir cómo han de diseñarse las estructuras de datos, 
cómo ha de implementarse la función dentro de una 
arquitectura de software, cómo han de implementarse 
los detalles procedimentales, cómo han de caracteri- 
zarse interfaces, cómo ha de traducirse el diseño en un 
lenguaje de programación (o lenguaje no procedimen- 
tal) y cómo ha de realizarse la prueba. Los métodos apli- 
cados durante la fase de desarrollo variarán, aunque las 
tres tareas específicas técnicas deberían ocurrir siem- 
pre: diseño del software (Capítulos 14, 15 y 21), gene- 
ración de código y prueba del software (Capítulos 16, 
17 y 22). 


ntó que debe haber una explicación 
lo noturaleza, porque Dios no es 
arbitrario. Esta fe no se ajusta al 
software. 


lo complejidad que debe dominar es 


Lafase de mantenimiento se centra en el cambio que 
va asociado a la corrección de errores, a las adaptacio- 
nes requeridas a medida que evoluciona el entorno del 
software y a cambios debidos a las mejoras producidas 
por los requisitos cambiantes del cliente. Durante la fase 
de mantenimiento se encuentran cuatro tipos de cam- 
bios: 

Corrección. Incluso llevando a cabo las mejores acti- 
vidades de garantía de calidad, es muy probable que el 
cliente descubra los defectos en el software. El mante- 
nimiento correctivo cambia el software para corregir los 
defectos. 


Adaptación. Con el paso del tiempo, es probable 
que cambie el entorno original (por ejemplo: CPU, el 
sistema operativo, las reglas de empresa, las caracte- 
rísticas externas de productos) para el que se desarro- 
lló el software. El mantenimiento adaptativo produce 
modificación en el software para acomodarlo a los cam- 
bios de su entorno externo. 


Mejora. Conforme se utilice el software, el clien- 
te/usuario puede descubrir funciones adicionales que 
van a producir beneficios. El mantenimiento perfectivo 
lleva al software más allá de sus requisitos funcionales 
originales. 


Prevención. El software de computadora se dete- 
riora debido al cambio, y por esto el mantenimiento pre- 
ventivo también llamado reingeniería del software, se 
debe conducir a permitir que el software sirva para las 
necesidades de los usuarios finales. En esencia, el man- 
tenimiento preventivo hace cambios en programas de 
computadora a fin de que se puedan corregir, adaptar y 
mejorar más fácilmente. 
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INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRACTICO 


Además de estas actividades de mantenimiento, los 
usuarios de software requieren un mantenimiento con- 
tinuo. Los asistentes técnicos a distancia, teléfonos de 
ayuda y sitios Web de aplicaciones específicas se imple- 
mentan frecuentemente como parte de la fase de man- 
tenimiento. 


Cionsuof) 


Cuando utilizamos el término «mantenimiento» 
reconocemos que es mucho más que una simple 
corrección de errores. 


Hoy en día, el aumento de los programas' legales 
está forzando a muchas compañías a seguir estrategias 
de reingeniería del software (Capítulo 30). En un sen- 
tido global, la reingeniería del software se considera a 
menudo como una parte de la reingeniería de procesos 
comerciales [STA9S]. 

Las fases y los pasos relacionados descritos en nues- 
tra visión genérica de la ingeniería del software se com- 
plementan con un número de actividades protectoras. 


Actividades de protección 
Entre las actividades típicas de esta categoría se incluyen: 
+. Seguimiento y control del proyecto de software 
+ Revisiones técnicas formales 
+. Garantía de calidad del software 
+ Gestión de configuración del software 
. Preparación y producción de documentos 
+ Gestión de reutilización 
+ Mediciones 
+ Gestión de riesgos 


Las actividades de protección se aplican a lo largo 
de todo el proceso del software y se tratan en las partes 
Segunda y Quinta del libro. 


Un proceso de software se puede caracterizar como se 
muestra en la Figura 2.2. Se establece un marco común 
del proceso definiendo un pequeño número de activida- 
des del marco de trabajo que son aplicables a todos los 
proyectos del software, con independenciade su tamaño 
ocomplejidad. Un número de conjuntos de tareas- cada 
uno es una colección de tareas de trabajo de ingeniería 
del software, hitos de proyectos, productos de trabajo, y 
puntos de garantía de calidad —que permiten que las acti- 
vidades del marco de trabajo se adapten a las caracterís- 
ticas del proyecto del software y alos requisitos del equipo 


Actividades del marco detrabajo 
Conjuntos de tareas 


Tareas * 
Hitos, entregas 


Puntos SQA 


FIGURA 2.2. El proceso del software. 


l E] término «programas legales» es un eufemismo para el sottware 
antiguo, a menudo diseñado y documentado pobremente, que es crí- 
tico para el negocio y debe ser soportado durante algunos años. 
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del proyecto. Finalmente, las actividades de protección 
—-+tales como garantía de calidad del software, gestión de 
configuración del software y medición* — abarcan el 
modelo de procesos. Las actividades de protección son 
independientes de cualquier actividad del marco de tra- 
bajo y aparecen durante todo el proceso. 

En los Últimos años, se ha hecho mucho énfasis en 
la «madurez del proceso». El Softwate Engineering Ins- 
titute (SED? ha desarrollado un modelo completo que 
se basa en un conjunto de funciones de ingeniería del 
software que deberían estar presentes conforme orga- 
nizaciones alcanzan diferentes niveles de madurez del 
proceso. Para determinar el estado actual de madurez 
del proceso de una organización, el SEI utiliza un cues- 
tionario de evaluación y un esquema de cinco grados. 


Consuo) 


Seleccione un marco de trabajo del proceso común que se 
adecue al producto, al personal y al proyecto. 


El esquema de grados determina la conformidad con 
un modelo de capacidad de madurez [PAU93] que defi- 
ne las actividades clave que se requieren en los dife- 
rentes niveles de madurez del proceso. El enfoque del 
SEI proporciona una medida de la efectividad global de 


2 Estos temas se tratan con más detalle en capítulos posteriores. 
3 El autor se está refiriendo al SEI de la Cannegie Mellon University. 
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las prácticas de ingeniería del software de una compa- 
ñía y establece cinco niveles de madurez del proceso, 
que se definen de la forma siguiente: 


Nivel 1: Inicial. El proceso del software se caracte- 
riza según el caso, y ocasionalmente incluso de forma 
caótica. Se definen pocos procesos, y el éxito depende 
del esfuerzo individual. 


Nivel 2: Repetible. Se establecen los procesos de 
gestión del proyecto para hacer seguimiento del coste, 
de la planificación y de la funcionalidad. Para repetir 
éxitos anterioresen proyectos con aplicaciones simila- 
res se aplica la disciplina necesaria para el proceso. 


Nivel 3: Definido. El proceso del software de las 
actividades de gestión y de ingeniería se documenta, se 
estandariza y se integra dentro de un proceso de soft- 
ware de toda una organización. Todos los proyectos uti- 
lizan una versión documentada y aprobada del proceso 
de la organización para el desarrollo y mantenimiento 
del software. En este nivel se incluyen todas las carac- 
terísticas definidas para el nivel 2. 


Nivel 4: Gestionado. Se recopilan medidas deta- 
lladas del proceso del software y de la calidad del pro- 
ducto. Mediante la utilización de medidas detalladas, 
se comprenden y se controlan cuantitativamente tan- 
to los productos como el proceso del software. En este 
nivel se incluyen todas las características definidas 
para el nivel 3. 

Nivel 5: Optimización. Mediante una retroalimen- 
tación cuantitativadel proceso, ideas y tecnologías inno- 
vadoras se posibilita una mejora del proceso. En este 
nivel se incluyen todas las características definidas para 
el nivel 4. 


EIIS ofrece un amplio conjunto de información 
relacionadacon el proceso en www.sei.cmu.edu 


Merece la pena destacar que cada nivel superior es 
la suma de los niveles anteriores, por ejemplo, un desa- 
rrolladorde softwareen el nivel 3 tiene que haber alcan- 
zado el estado nivel 2 para poder disponer de sus 
procesos en el nivel 3. 

El nivel 1 representa una situación sin ningún esfuer- 
zoen la garantía de calidad y gestión del proyecto, don- 
de cada equipo del proyecto puede desarrollar software 
de cualquier forma eligiendo los métodos, estándares y 
procedimientos a utilizar que podrán variar desde lo 
mejor hasta lo peor. 

El nivel 2 representa el hecho de que un desarrolla- 
dor de software ha definido ciertas actividades tales 
como el informe del esfuerzo y del tiempo empleado, y 
el informe de las tareas realizadas. 

El nivel 3 representa el hecho de que un desarrolla- 
dor de software ha definidotanto procesos técnicos como 
de gestión, por ejemplo un estándar para la programa- 
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ción ha sido detallado y se hace cumplir por medio de 
procedimientos tales como auditorías. Este nivel es aquel 
en el que la mayoría de los desarrolladores de softwa- 
re, pretenden conseguir con estándares como el ISO 
9001, y existen pocos casos de desarrolladores de soft- 
ware que superan este nivel. 

El nivel 4 comprende el concepto de medición y el 
uso de métricas. El capítulo4 describe este tema con más 
detalle. Sinembargo,cabe destacarel conceptode métri- 
ca para comprenderla importanciaque tiene que el desa- 
rrollador del software alcance el nivel 4 o el nivel 5. 

Una métrica es una cantidad insignificanteque puede 
extraerse de algún documentoo código dentro de un pro- 
yecto de software. Un ejemplo de métrica es el número 
de ramas condicionales en una sección de código de un 
programa. Esta métrica es significativaen el sentido de 
que proporciona alguna indicación del esfuerzo necesa- 
rio para probar el código: está directamente relacionado 
con el número de caminos de prueba dentro del código. 
Una organización del nivel 4 maneja numerosas 
métricas. Estas métricas se utilizan entonces para super- 
visar y controlar un proyecto de software, por ejemplo: 


+ Una métrica de prueba puede usarse para determinar 
cuándo finalizar la prueba de un elemento del código. 
+ Una métrica de legilibilidad puede usarse para juz- 


gar la legilibilidad de algún documento en lenguaje 
natural. 


+. Una métrica de comprensión del programa puede uti- 
lizarse para proporcionar algún umbral numérico que 
los programadores no pueden cruzar. 


Para que estas métricas alcancen este nivel es nece- 
sario que todos los componentes del nivel 3 CMM, en 
castellano MCM (Modelo de Capacidad de Madurez), 
estén conseguidos, por ejemplo notaciones bien defini- 
das para actividades como la especificación del diseño 
de requisitos, por lo que estas métricas pueden ser fácil- 
mente extraídas de modo automático. 


El nivel 5 es el nivel más alto a alcanzar. Hasta aho- 
ra, muy pocos desarrolladores de software han alcan- 
zado esta fase. Representa la analogía del software con 
los mecanismos de control de calidad que existen en 
otras industrias de mayor madurez. Por ejemplo el fabri- 
cante de un producto industrial como un cojinete de 
bolas (rodamiento) puede supervisar y controlar la cali- 
dad de los rodamientos producidos y puede predecir esta 
calidad basándose en los procesos y máquinas utiliza- 
dos para desarrollar los rodamientos. Del mismo modo 
que el desarrollador del sofware en el nivel 5 puede pre- 
decir resultados como el número de errores latentes en 
un producto basado en la medición tomada durante la 
ejecución de un proyecto. Además, dicho desarrollador 
puede cuantificar el efecto que un proceso nuevo O herra- 
mienta de manufacturación ha tenido en un proyecto 
examinando métricas para ese proyecto y comparándo- 
las con proyectos anteriores que no utilizaron ese pro- 
ceso O herramienta. 
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INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRÁCTICO 


En este orden debe destacarse que para que un desa- 
rrollador de software alcance el nivel 5 tiene que tener 
cada proceso definido rigurosamente y seguirlo al pie 
de la letra; esto es una consecuencia de estar en el 
nivel 3. Si el desarrollador del software no tiene defi- 
nidos rigurosamente los procesos pueden ocurrir una 
gran cantidad de cambios en el proceso de desarrollo 
y no se podrán utilizar las estadísticas para estas acti- 
vidades. 

Los cinco niveles definidos por el SEI se obtienen 
como consecuencia de evaluar las respuestas del cues- 
tionario de evaluación basado en el MCM (Modelo de 
capacidad de madurez). Los resultados del cuestiona- 
rio se refinan en un único grado numérico que propor- 
ciona una indicación de la madurez del proceso de una 
organización. 

El SEÍ ha asociado áreas claves del proceso 
(ACPs) a cada uno de los niveles de madurez. Las 
ACPs describen esas funciones de la ingeniería del 
software (por ejemplo: planificación del proyecto de 
software, gestión de requisitos) que se deben pre- 
sentar para satisfacer una buena práctica a un nivel 
en particular. Cada ACP se describe identificando las 
características siguientes: 


los 


lodo organización debería esforzarseporo alcanzar 
lo profundidad del MCM del!IS. Sinembargo, 

lo implementación de cualquier aspecto del modelo 
puede eliminarse en su situación. 


» Objetivos — los objetivos globales que debe alcan- 
zar la ACP 


*» Compromisos — requisitos (impuestos en la organi- 
zación) que se deben cumplir para lograr los objeti- 
vos y que proporcionan una prueba del intento por 
ajustarse a los objetivos. 


» Capacidades —aquellos elementos que deben encon- 
trarse (organizacional y técnicamente) para permitir 
que la organización cumpla los objetivos. 


» Actividades — las tareas específicas que se requieren 
para lograr la función ACP. 


* Métodos para supervisar la implementación — la 
manera en que las actividades son supervisadas con- 
forme se aplican. 


» Métodos para verificar la implementución —la forma 
en que se puede verificar la práctica adecuada para 
la ACP. 


Se definen dieciocho ACPs (descritas mediante la 
estructura destacada anteriormente) en el modelo de 
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Referencia Web 


Una versión tabular del MCM completo del IS, incluyendo 
todos los objetivos, comentarios, habilidades y 
actividades está disponible en 

sepo.nosc.mil /CMMmatrices.html 


madurez y se distribuyen en niveles diferentes de madu- 
rez del proceso. Las ACPs se deberían lograr en cada 
nivel de madurez de proceso”: 


Nivel 2 de Madurez del Proceso 

+ Gestión de configuración del software 

+ Garantía de calidad del software 

» Gestión de subcontratación del software 

+ Seguimiento y supervisión del proyecto del software 

» Planificación del proyecto del software 

+ Gestión de requisitos 

Nivel 3 de Madurez del Proceso 

+ Revisiones periódicas 

» Coordinación entre grupos 

» Ingeniería de productos de software 

» Gestión de integración del software 

» Programa de formación 

* Definición del proceso de la organización 

« Enfoque del proceso de la organización 

Nivel 4 de Madurez del Proceso 

+ Gestión de calidad del software 

» Gestión cuantitativa del proceso 

Nivel 5 de Madurez del Proceso 

+ Gestión de cambios del proceso 

+ Gestión de cambios de tecnología 

» Prevención de defectos 

Cada una de las ACPs se definen con un conjunto 
deprácticas clave que contribuyen a cumplirestos obje- 
tivos. Las prácticas clave son normas, procedimientos 
y actividades que deben ocurrir antes de que se haya 
instituido completamente un área clave de proceso. El 
SEI define a los indicadores clave como «aquellas prác- 
ticas clave O componentes de prácticas clave que ofre- 
cen una visión mejor para lograr los objetivos de un 
área clave de proceso». Las cuestiones de valoración 


se diseñan para averiguar la existencia (o falta) de un 
indicador clave. 


4 Téngase en cuenta que las ACPs son acumulativas. Por ejemplo, el 
nivel 3 de madurez del proceso contiene todas las ACPs del nivel 2 
más las destacadas para el nivel 1. 
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CAPÍTULO 2 EL PROCESO 


Para resolver los problemas reales de una industria, un 
ingeniero del software o un equipo de ingenieros debe 
incorporar una estrategia de desarrollo que acompañe 
al proceso, métodos y capas de herramientas descritos 
en la Sección 2.1.1 y las fases genéricas discutidas en 
la Sección 2.1.2. Esta estrategia a menudo se llama 
modelo de proceso oparadigma de ingeniería del soft- 
ware. Se selecciona un modelo de proceso para la inge- 
niería del software según la naturaleza del proyecto y 
de la aplicación, los métodos y las herramientas a utili- 
zarse, y los controles y entregas que se requieren. En 
un documento intrigante sobre la naturaleza del proce- 
so del software, L.B.S. Raccoon [RAC95] utiliza frac- 
tales como base de estudio de la verdadera naturaleza 
del proceso del software. 


|ivobojo del softwore sigue la 
Joy del cidismo: no importa dónde voyos, ya 
rribo y contra el viento. 


Todo el desarrollo del software se puede caracteri- 
zar como bucle de resolución de problemas (Fig. 2.3a) 
en el que se encuentran cuatro etapas distintas: «status 
quo», definición de problemas, desarrollo técnico e inte- 
gración de soluciones. Status quo «representa el estado 
actual de sucesos» [RAC95]; la definición de proble- 
mas identifica el problema específico a resolverse; el 
desarrollo técnico resuelve el problema a través de la 
aplicación de alguna tecnología y la integración de solu- 
ciones ofrece los resultados (por ejemplo: documentos, 
programas, datos, nueva función comercial, nuevo pro- 
ducto) a los que solicitan la solución en primer lugar. 
Las fases y los pasos genéricos de ingeniería del soft- 
ware definidos en la Sección 2.1.2 se divide fácilmen- 
te en estas etapas. A 

En realidad, es difícil compartimentar actividades de 
manera tan nítida como la Figura 2.3.b da a entender, 
porque existen interferencias entre las etapas. Aunque 
esta visión simplificada lleva a una idea muy impor- 
tante: con independencia del modelo de proceso que se 
seleccione para un proyecto de software, todas las eta- 
pas —status quo, definición de problemas, desarrollo 
técnico e integración de soluciones — coexisten simul- 
táneamente en algún nivel de detalle. Dada la naturale- 
za recursiva de la Figura2.3b, las cuatro etapas tratadas 
anteriormente se aplican igualmente al análisis de una 
aplicación completa y a la generación de un pequeño 
segmento de código. 

Raccoon [RAC95] sugiere un «Modelo del Caos» 
que describe el «desarrollodel software como una exten- 
sión desde el usuario hasta el desarrollador y la tecno- 
logía». Conforme progresa el trabajo hacia un sistema 
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completo, las etapas descritas anteriormente se aplican 
recursivamentea las necesidades del usuario y a la espe- 
cificación técnica del desarrollador del software. 


pr 
VE 


Todas los etapas de un proceso del software - estado 
actual, definición del problema, desarrollo técnico e 
integración de la solución — coexisten simultáneamente 
en algún nivel de detalle. 


En las secciones siguientes, se tratan diferentes mode- 
los de procesos para la ingeniería del software. Cada 
una representa un intento de ordenar una actividad inhe- 
rentemente caótica. Es importante recordar que cada 
uno de los modelos se han caracterizado de forma que 
ayuden (con esperanza) al control y a la coordinación 
de un proyecto de software real. Y a pesar de eso, en el 
fondo, todos los modelos exhiben características del 
«Modelo del Caos». 


Definición 
de problemas 


Desarrollo 
técnico 


Estado 
actual 


Integración 
de soluciones 


Estado 
actual 


FIGURA 2.3.a) Las fases de un bucle de resolución de pro- 
blemas [RAC 951. b) Fases dentro de las fases 
del bucle de resolución de problemas [RAC 95]. 
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INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRÁCTICO 


Llamado algunas veces «ciclo de vida básico» o «mode- 
lo en cascada», el modelo lineal secuencial sugiere un 
enfoque? sistemático, secuencial, para el desarrollo del 
software que comienza en un nivel de sistemas y pro- 
gresa con el análisis, diseño, codificación, pruebas y man- 
tenimiento. La Figura 2.4 muestra el modelo lineal 
secuencial para la ingeniería del software. Modelado 
según el ciclo de ingeniería convencional, el modelo 
lineal secuencial comprende las siguientes actividades: 


Ingeniería y modelado de Sistemas/Información. 
Como el software siempre forma parte de un sistema 
más grande (o empresa), el trabajo comienza estable- 
ciendo requisitos de todos los elementos del sistema y 
asignando al software algún subgrupo de estos requisi- 
tos. Esta visión del sistema es esencial cuando el soft- 
ware se debe interconectar con otros elementos como 
hardware, personas y bases de datos. La ingeniería y el 
análisis de sistemas comprende los requisitos que se 
recogen en el nivel del sistema con una pequeña parte 
de análisis y de diseño. La ingeniería de información 
abarca los requisitos que se recogen en el nivel de 
empresa estratégico y en el nivel del área de negocio. 


Ingeniería de 
sistemas/información 


Análisis 


FIGURA 2.4. El modelo lineal secuencial. 


Análisis de los requisitos del software. El proceso 
de reunión de requisitos se intensifica y se centra espe- 
cialmente en el software. Para comprenderla naturaleza 
del (los) programa(s) a construirse, el ingeniero («ana- 
lista») del software debe comprender el dominio de 
información del software (descrito en el Capítulo 11), así 
como la función requerida, comportamiento,rendimien- 
to e interconexión. 


Diseño. El diseño del software es realmente un pro- 
ceso de muchos pasos que se centra en cuatro atributos 
distintos de programa: estructura de datos, arquitectu- 
ra de software, representaciones de interfaz y detalle 
procedimental (algoritmo). El proceso del diseño tra- 
duce requisitos en una representación del software donde 


5 Aunque el modelo original en cascada propuesto por Winston Royce 
[ROY70] hacía provisiones para «bucles de realimentación», la gran 
mayoría de las organizaciones que aplican este modelo de proceso 
lo hacen como si fuera estrictamente lineal. 
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se pueda evaluar su calidad antes de que comience la 
codificación. 

Generación de código. El diseño se debe traducir 
en una forma legible por la máquina. El paso de gene- 
ración de código lleva a cabo esta tarea. Si se lleva a 
cabo el diseño de una forma detallada, la generación de 
código se realiza mecánicamente. 


Cons) 


Aunque el modelo lineales a menudo denominado 
«modelo tradicional», resulto un enfoque razonable 
cuando los requisitosse han entendido correctomente. 


Pruebas. Una vez que se ha generado el código, 
comienzan las pruebas del programa. El proceso de prue- 
bas se centra en los procesos lógicos internos del soft- 
ware, asegurando que todas las sentencias se han 
comprobado, y en los procesos externos funcionales; es 
decir, realizar las pruebas para la detección de errores 
y asegurar que la entrada definida produce resultados 
reales de acuerdo con los resultados requeridos. 


Mantenimiento. El software indudablemente sufrirá 
cambios después de ser entregado al cliente (una excep- 
ción posible es el software empotrado). Se producirán 
cambios porque se han encontrado errores, porque el soft- 
ware debe adaptarse para acoplarse a los cambios de su 
entorno externo (por ejemplo: se requiere un cambio debi- 
do a un sistema operativo o dispositivo periférico nue- 
vO), O porque el cliente requiere mejoras funcionales o 
de rendimiento. El soporte y mantenimiento del softwa- 
re vuelve a aplicar cada una de las fases precedentes a un 
programa ya existente y no a uno nuevo. 


El modelo lineal secuencial es el paradigma más anti- 
guo y más extensamente utilizado en la ingeniería del 
software. Sin embargo, la crítica del paradigma ha pues- 
to en duda su eficacia [HAN95]. Entre los problemas 
que se encuentran algunas veces en el modelo lineal 
secuencial se incluyen: 


¿Por qué falla algunas veces 
el modelo lineal? 


1. Los proyectos reales raras veces siguen el modelo 
secuencial que propone el modelo. Aunque el modelo 
lineal puede acoplar interacción, lo hace indirecta- 
mente. Como resultado, los cambios pueden causar 
confusión cuando el equipo del proyecto comienza. 


www.elsolucionario.net 


2. A menudo es difícil que el cliente exponga explíci- 
tamente todos los requisitos. El modelo lineal secuen- 
cial lo requiere y tiene dificultades a la hora de 
acomodar la incertidumbre natural al comienzo de 
muchos proyectos. 


3. El cliente debe tener paciencia. Una versión de tra- 
bajo del (los) programa(s) no estará disponible hasta 
que el proyecto esté muy avanzado. Un grave error 
puede ser desastroso si no se detecta hasta que se 
revisa el programa. 


CAPÍTULO 2 EL PROCESO 


Cada uno de estos errores es real. Sin embargo, el 
paradigma del ciclo de vida clásico tiene un lugar defi- 
nido e importante en el trabajo de la ingeniería del soft- 
ware. Proporciona una plantilla en la que se encuentran 
métodos para análisis, diseño, codificación, pruebas y 
mantenimiento. El ciclo de vida clásico sigue siendo el 
modelo de proceso más extensamente utilizado por la 
ingeniería del software. Pese a tener debilidades, es sig- 
nificativamente mejor que un enfoque hecho al azar para 
el desarrollo del software. 


Un cliente, a menudo, define un conjunto de objetivos 
generales para el software, pero no identifica los requi- 
sitos detallados de entrada, proceso o salida. En otros 
casos, el responsable del desarrollo del software puede 
no estar seguro de la eficacia de un algoritmo, de la capa- 
cidad de adaptación de un sistema operativo, o de la for- 
ma en que debería tomarse la interacción hombre- 
máquina. En estas y en otras muchas situaciones, un 
paradigma de construcción de prototipos puede ofre- 
cer el mejor enfoque. 

El paradigma de construcción de prototipos (Fig. 
2.5) comienza con la recolección de requisitos. El desa- 
rrollador y el cliente encuentran y definen los objeti- 
vos globales para el software, identifican los requisitos 
conocidos y las áreas del esquema en donde es obli- 
gatoria más definición. Entonces aparece un «diseño 
rápido». El diseño rápido se centra en una representa- 
ción de esos aspectos del software que serán visibles 
para el usuario/cliente (por ejemplo: enfoques de entra- 
da y formatos de salida). El diseño rápido lleva a la 
construcción de un prototipo. El prototipo lo evalúa el 
clientefusuario y se utiliza para refinar los requisitos 
del software a desarrollar. La iteración ocurre cuando 
el prototipo se pone a punto para satisfacer las nece- 
sidades del cliente, permitiendo al mismo tiempo que 
el desarrollador comprenda mejor lo que se necesita 
hacer. 


Rionsuof) 


Cuando el cliente tiene uno necesidad legítima, 
pero está desorientado sobre los detalles, 
el primer poso es desarrollar un prototipo. 


Lo ideal sería que el prototipo sirviera como un meca- 
nismo para identificar los requisitos del software. Si se 
construye un prototipo de trabajo, el desarrolladorinten- 
ta hacer uso de los fragmentos del programa ya exis- 
tentes o aplica herramientas (por ejemplo: generadores 
de informes, gestores de ventanas, etc.) que permiten 
generar rápidamente programas de trabajo. 
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Construir/revisar 
la maqueta 


Escuchar 
al cliente 


El cliente 
prueba 
la maqueta 


FIGURA 2.5. El paradigma de construcción de prototipos. 


Pero ¿qué hacemos con el prototipo una vez que ha 
servidopara el propósito descrito anteriormente?Brooks 
[BRO75] proporciona una respuesta: 


En la mayoría de los proyectos, el primer sistema construido 
apenas se puede utilizar. Puede ser demasiado lento, demasiado 
grande o torpe en su uso, o las tres a la vez. No hay otra alterna- 
tiva que comenzar de nuevo, aunque nos duela pero es más inte- 
ligente, y construir una versión rediseñada en la que se resuelvan 
estos problemas ... Cuando se utiliza un concepto nuevo de siste- 
ma o una tecnología nueva, se tiene que construir un sistema que 
no sirva y se tenga que tirar, porque incluso la mejor planificación 
no es omnisciente como para que esté perfecta la primera vez. Por 
lo tanto la pregunta de la gestión no es si construir un sistema pilo- 
to y tirarlo. Tendremos que hacerlo. La Unica pregunta es si pla- 
nificar de antemano construir un desechable, o prometer 
entregárseloa los clientes... 


El prototipo puede servir como «primer sistema». 
El que Brooks recomienda tirar. Aunque esta puede ser 
una visión idealizada. Es verdad que a los clientes y a 
los que desarrollan les gusta el paradigma de cons- 
trucción de prototipos. A los usuarios les gusta el sis- 
tema real y a los que desarrollan les gusta construir algo 
inmediatamente. Sin embargo, la construcción de pro- 
totipos también puede ser problemática por las siguien- 
tes razones: 
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INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRÁCTICO 


1. El cliente ve lo que parece ser una versión de trabajo 
del software, sin tener conocimiento de que el pro- 
totipo también estájunto con «el chicle y el cable de 
embalar», sin saber que con la prisa de hacer que 
funcioneno se ha tenido en cuenta la calidad del soft- 
ware global o la facilidad de mantenimiento a largo 
plazo. Cuando se informa de que el producto se debe 
construir otra vez para que se puedan mantener los 
niveles altos de calidad, el cliente no lo entiende y 
pide que se apliquen «unos pequeños ajustes» para 
que se pueda hacer del prototipo un producto final. 
De forma demasiado frecuente la gestión de desa- 
rrollo del software es muy lenta. 


. El desarrollador, a menudo, hace compromisos de 
implementación para hacer que el prototipo funcione 
rápidamente. Se puede utilizar un sistema operativo 
o lenguaje de programación inadecuado simplemente 
porque está disponible y porque es conocido; un algo- 
ritmo eficiente se puede implementar simplemente 


para demostrar la capacidad. Después de algún 
tiempo, el desarrolladordebe familiarizarsecon estas 
selecciones, y olvidarse de las razones por las que 
son inadecuadas. La selección menos ideal ahora es 
una parte integral del sistema. 


Cionsuof) 


Resistolo presión de ofrecer un mal prototipo en el 
producto final. Cornoresultado, lo colidodse resiente casi 
siempre. 


Aunque pueden surgir problemas, la construcción de 
prototipos puede ser un paradigma efectivo para la inge- 
niería del software. La clave es definirlas reglas deljue- 
go al comienzo; es decir, el cliente y el desarrollador se 
deben poner de acuerdo en que el prototipo se constru- 
ya para servir como un mecanismo de definición de 
requisitos. 


lo de proceso del desarrollo del software lineal secuencial 
que enfatiza un ciclo de desarrollo extremadamentecor- 
to. El modelo DRA es una adaptación a «alta velocidad» 
del modelo lineal secuencial en el que se logra el desa- 
rrollo rápido utilizando una construcción basada en com- 
ponentes. Si se comprenden bien los requisitos y se limita 
el ámbito del proyecto, el proceso DRA permite al equi- 
po de desarrollo crear un «sistema completamente fun- 
cional» dentro de períodos cortos de tiempo (porejemplo: 
de 60 a 90 días) [MAR91]. Cuando se utiliza principal- 
mente para aplicaciones de sistemas de información, el 
enfoque DRA comprende las siguientes fases [KER94]: 


Modelado de Gestión. El flujo de información entre 
las funciones de gestión se modela de forma que res- 
ponda a las siguientes preguntas: ¿Qué información con- 
duce el proceso de gestión? ¿Qué información se genera? 
¿Quién la genera? ¿A dónde va la información? ¿Quién 
la procesa? El modelado de gestión se describe con más 
detalle en el Capítulo 10. 


Modelado de datos. El flujo de información defini- 
do como parte de la fase de modelado de gestión se refi- 
na como un conjuntode objetos de datos necesariospara 
apoyar la empresa. Se definen las características (lla- 
madas atributos) de cada uno de los objetos y las rela- 
ciones entre estos objetos. El modelado de datos se trata 
en el Capítulo 12. 


Modelado del proceso. Los objetos de datos defi- 
nidos en la fase de modelado de datos quedan transfor- 
mados para lograr el flujo de información necesariopara 
implementar una función de gestión. Las descripciones 
del proceso se crean para añadir, modificar, suprimir, o 
recuperar un objeto de datos. 


* En ingles: RAD (Rapid Application Deveiopment) 
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Generación de aplicaciones. El DRA asume la uti- 
lización de técnicas de cuarta generación (Sección 2.10). 
En lugar de crear software con lenguajes de programa- 
ción de tercera generación, el proceso DRA trabaja para 
volver a utilizar componentes de programas ya exis- 
tentes (cuando es posible) o a crear componentes reuti- 
lizables (cuando sea necesario). En todos los casos se 
utilizan herramientas para facilitar la construcción del 
software. 


Equipo n* 


Equipo n* 2 


Modelado 
degestión 


Modelado 
de datos 


Equipo n? 1 


Modelado 
de gestión 


Generación 


: de. 
aplicacionesj 


Modelado 
de procesos 


Generación 


aplicaciones 


Pruebas 
y entrega 


(00 días 


FIGURA 2.6.El modelo DRA. 
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Pruebas y entrega. Como el proceso DRA enfati- 
za la reutilización, ya se han comprobado muchos de 
los componentes de los programas. Esto reduce tiempo 
de pruebas. Sin embargo, se deben probar todos los com- 
ponentes nuevos y se deben ejercitar todas las interfa- 
ces a fondo. 


Referencia cruzada 


EEDRÁ hace un fuerte uso de componentes 
reutilizables, Paro mayor información sobre el 
desarrollo de componentes, véase el Capítulo 27. 


El modelo de proceso DRA se ilustra en la Figura 
2.6. Obviamente, las limitaciones de tiempo impuestas 
en un proyecto DRA demandan «ámbito en escalas» 
[KER94]. Si una aplicación de gestión puede modular- 
se de forma que permita completarse cada una de las 
funciones principales en menos de tres meses (utilizando 
el enfoque descrito anteriormente), es un candidato del 
DRA. Cada una de las funciones pueden ser afrontadas 
por un equipoDRA separado y ser integradas en un solo 
conjunto. 


CAPÍTULO 2 EL PROCESO 


Al igual que todos los modelos de proceso, el enfo- 
que DRA tiene inconvenientes [BUT94]: 


» Paraproyectos grandes aunque por escalas, el DRA 
requiere recursos humanos suficientes como para 
crear el número correcto de equipos DRA. 


+ DRArequiere clientes y desarrolladores compro- 
metidos en las rápidas actividades necesarias para 
completar un sistema en un marco de tiempo abre- 
viado. Sino hay compromiso por ninguna de las par- 
tes constituyentes, los proyectos DRA fracasarán. 


» No todos los tipos de aplicaciones son apropiados 
para DRA. Si un sistema no se puede modularizar 
adecuadamente, la construcción de los componentes 
necesarios para DRA será problemático. Si está en 
juego el alto rendimiento, y se va a conseguir el ren- 
dimiento convirtiendo interfaces en componentes de 
sistemas, el enfoque DRA puede que no funcione. 


+ DRAnoes adecuado cuando los riesgos técnicos son 
altos. Esto ocurre cuando una nueva aplicación hace 
uso de tecnologías nuevas, o cuando el software 
nuevo requiere un alto grado de interoperatividad 
con programas de computadora ya existentes. 


Se reconoce que el software, al igual que todos los sis- 
temas complejos, evoluciona con el tiempo [GIL88)]. 
Los requisitos de gestión y de productos a menudo cam- 
bian conforme a que el desarrolloproceda haciendo que 
el camino que lleva al producto final no sea real; las 
estrictas fechas tope del mercado hacen que sea impo- 
sible finalizar un producto completo, por lo que se debe 
introducir una versión limitada para cumplir la presión 
competitiva y de gestión; se comprende perfectamente 
el conjunto de requisitos de productos centrales o del 
sistema, pero todavía se tienen que definir los detalles 
de extensiones del producto o sistema. En estas y en 
otras situaciones similares, los ingenieros del software 
necesitan un modelo de proceso que se ha diseñado 
explícitamente para acomodarse a un producto que evo- 
lucione con el tiempo. 

El modelo lineal secuencial (Sección 2.4) se diseña 
para el desarrollo en línea recta. En esencia, este enfo- 
que en cascada asume que se va entregar un sistema 
completo una vez que la secuencia lineal se haya fina- 
lizado. El modelo de construcción de prototipos (Sec- 
ción 2.5) se diseña para ayudar al cliente (o al que 
desarrolla) a comprender los requisitos. En general, no 
se diseña para entregar un sistema de producción. En 
ninguno de los paradigmas de ingeniería del software 
se tiene en cuenta la naturaleza evolutiva del software. 

Los modelos evolutivos son iterativos. Se caracterl- 
zan por la forma en que permiten a los ingenieros del 
software desarrollar versiones cada vez más completas 
del software. 
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2.7.1. El modelo incremental 


El modelo incrernental combina elementos del modelo 
lineal secuencial (aplicados repetidamente) con la filo- 
sofía interactiva de construcción de prototipos. Como 
muestra la Figura 2.7, el modelo incremental aplica 
secuencias lineales de forma escalonada mientras pro- 
gresa el tiempo en el calendario. Cada secuencia lineal 
produce un «incremento» del software [MDE93]. Por 
ejemplo, el software de tratamiento de textos desarro- 
llado con el paradigma incremental podría extraer fun- 
ciones de gestión de archivos básicos y de producción 
de documentos en el primer incremento; funciones de 
edición más sofisticadas y de producción de documen- 
tos en el segundo incremento; corrección ortográfica y 
gramatical en el tercero; y una función avanzada de 
esquema de página en el cuarto. Se debería tener en cuen- 
ta que el flujo del proceso de cualquier incremento pue- 
de incorporarel paradigma de construcción de prototipos. 


a 
S 


CLAVE 


Enmodeloincremental entrega el software en partes 
pequeñas, pero utilizables, llamadas ((incrementos). 
En general, cado incremento se construye sobre aquél 
que ya ho sido entregado. 


Cuando se utiliza un modelo incremental, el primer 
incremento a menudo es un producto esencial. Es decir, 
se afrontan requisitos básicos, pero muchas funciones 
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suplementarias(algunas conocidas, otras no) quedan sin 
extraer. El cliente utiliza el producto central (o sufre la 
revisión detallada). Como un resultado de utilización y/o 
de evaluación, se desarrolla un plan para el incremento 
siguiente. El plan afronta la modificación del producto 
central a fin de cumplir mejor las necesidades del clien- 
te y la entrega de funciones, y características adiciona- 
les. Este proceso se repite siguiendo la entrega de cada 
incremento, hasta que se elabore el producto completo. 


Consuo) 


Cuando tenga una fecha de entregaimposible 
de cambiar, el modela incrementales un buen 
paradigma a considerar. 


Ingeniería de 
Sistemas/información 


Análisis Diseño 


incremento 1 


El modelo de proceso incremental, como la cons- 
trucción de prototipos (Sección 2.5) y otros enfoques 
evolutivos, es iterativo por naturaleza. Pero a dife- 
rencia de la construcción de prototipos, el modelo 
incremental se centra en la entrega de un producto 
operacional con cada incremento. Los primeros incre- 
mentos son versiones «incompletas» del producto 
final, pero proporcionan al usuario la funcionalidad 
que precisa y también una plataforma para la eva- 
luación. 

El desarrollo incremental es particularmente útil 
cuando la dotación de personal no está disponible para 
una implementación completa en la fecha límite que se 
haya establecido para el proyecto. Los primeros incre- 
mentos se pueden implementar con menos personas. 


Entrega del 


> 
incremento 4 | Análisis Código Prueba Entrega del 
4. incremento 


1. incremento 


Entrega del 
2." incremento 


Entrega del 
3. incremento 


Tiempo de calendario 


FIGURA 2.7. El modelo incremental. 


2.7.2. El modelo espiral 


El modelo en espiral, propuesto originalmente por 
Boehm [BOE88], es un modelo de proceso de soft- 
ware evolutivo que conjuga la naturaleza iterativa de 
construcción de prototipos con los aspectos controla- 
dos y sistemáticos del modelo lineal secuencial. Pro- 
porciona el potencial para el desarrollo rápido de 
versiones incrementales del software. En el modelo 
espiral, el software se desarrolla en una serie de ver- 
siones incrementales. Durante las primeras iteraccio- 
nes, la version incremental podría ser un modelo en 
papel o un prototipo. Durante las últimas iteraciones, 
se producen versiones cada vez más completas del sis- 
tema diseñado. 
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Alariificación Análisis de riesgos 
Comunicación 9 
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Eje de punto de 
entrada de proyectq 
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Evaluación 
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LT] Proyectode mantenimiento de productos. 
TC] Proyectode mejora de productos. 

Proyecto de desarrollo de nuevos productos. 
E Proyecto de desarrollo de conceptos. 


FIGURA 2.8. Un modelo espiral típico. 
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El modelo en espiral se divide en un número de acti- 
vidades de marco de trabajo, también llamadas regio- 
nes de tareas”. Generalmente, existen entre tres y seis 
regiones de tareas. La Figura 2.8 representa un modelo 
en espiral que contiene seis regiones de tareas: 


- comunicación con el cliente — las tareas requeridas 
para establecer comunicación entre el desarrollador 
y el cliente. 


+ planificación— las tareas requeridas para definir 
recursos, el tiempo y otra información relacionadas 
con el proyecto. 


» análisis de riesgos — las tareas requeridas para eva- 
luar riesgos técnicos y de gestión. 


+ ingeniería— las tareas requeridas para construir una 
o más representaciones de la aplicación. 


» construcción y acción — las tareas requeridas para 
construir, probar, instalar y proporcionar soporte al 
usuario (por ejemplo: documentación y práctica) 


+ evaluación del cliente— las tareas requeridas para 
obtener la reacción del cliente según la evaluación 
de las representaciones del software creadas durante 
la etapa de ingeniería e implementada durante la 
etapa de instalación. 


e 
CLAVE 


Las actividades del marco de trabajo se aplican 
a cualquier proyecto de software que realice, 
sin tener en cuenta el tamaño ni la complejidad. 


Cada una de las regiones están compuestas por un con- 
junto de tareas del trabajo, llamado conjunto de tareas, 
que se adaptan a las características del proyecto que va 
a emprenderse. Para proyectos pequeños, el número de 
tareas de trabajo y su formalidades bajo. Para proyectos 
mayores y más críticos cada región de tareas contiene 
tareas de trabajo que se definen para lograr un nivel más 
alto de formalidad. Enrtodos los casos, se aplican las acti- 
vidades de protección (por ejemplo: gestión de configu- 
ración del software y garantía de calidad del software) 
mencionadas en la Sección 2.2. 


8), ¿Qué es un conjunto de 
tareas? 


Cuando empieza este proceso evolutivo, el equipo 
de ingeniería del software gira alrededor de la espiral 
en la dirección de las agujas del reloj, comenzando por 
el centro. El primer circuito de la espiral puede produ- 
cirel desarrollo de una especificación de productos; los 
pasos siguientes en la espiral se podrían utilizar para 
desarrollar un prototipo y progresivamente versiones 


$ El modelo en espiral de esta sección es una variante sobre el modelo 
propuesto por Boehm. Para más información sobre el modelo en espi- 
ral original, consulte [BOE88]. Un tratado más reciente del modelo 
en espiral puede encontrarse en [BOE98]. 
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más sofisticadas del software. Cada paso por la región 
de planificación produce ajustes en el plan del proyec- 
to. El coste y la planificación se ajustan con la reali- 
mentacion ante la evaluación del cliente. Además, el 
gestor del proyecto ajusta el número planificado de ¡te- 
raciones requeridas para completar el software. 


Modelo de proceso adaptable. 


A diferencia del modelo de proceso clásico que ter- 
mina cuando se entrega el software, el modelo en espi- 
ral puede adaptarse y aplicarse a lo largo de la vida del 
software de computadora. Una visión alternativa del 
modelo en espiral puede ser considerada examinando 
el eje depunto de entrada en elproyecto también refle- 
jado en la Figura 2.8. Cada uno de los cubos situados a 
lo largo del eje pueden usarse para representar el pun- 
to de arranque para diferentes tipos de proyectos. Un 
«proyecto de desarrollo de conceptos» comienza en el 
centro de la espiral y continuará (aparecen múltiples ite- 
raciones a lo largo de la espiral que limita la región som- 
breada central) hasta que se completa el desarrollo del 
concepto. Si el concepto se va a desarrollar dentro de 
un producto real, el proceso continúa a través del cubo 
siguiente (punto de entrada del proyecto de desarrollo 
del producto nuevo) y se inicia un «nuevo proyecto de 
desarrollo”. El producto nuevo evolucionará a través de 
iteraciones alrededor de la espiral siguiendo el camino 
que limita la región algo más brillante que el centro.En 
esencia, la espiral, cuando se caracteriza de esta forma, 
permanece operativa hasta que el software se retira. Hay 
veces en que el proceso está inactivo, pero siempre que 
se inicie un cambio, el proceso arranca en el punto de 
entrada adecuado (por ejemplo: mejora del producto). 

El modelo en espiral es un enfoque realista del desa- 
rrollo de sistemas y de software a gran escala. Como el 
software evoluciona, a medida que progresa el proceso 
el desarrollador y el cliente comprenden y reaccionan 
mejor ante riesgos en cada uno de los niveles evoluti- 
vos. El modelo en espiral utiliza la construcción de pro- 
totipos como mecanismo de reducción de riesgos, pero, 
lo que es más importante, permite a quien lo desarrolla 
aplicar el enfoque de construcciónde prototipos en cual- 
quier etapa de evolución del producto. Mantiene el enfo- 
que sistemático de los pasos sugeridos por el ciclo de 
vida clásico, pero lo incorpora al marco de trabajo ite- 
rativo que refleja de forma más realista el mundo real. 
El modelo en espiral demanda una consideración direc- 
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ta de los riesgos técnicos en todas las etapas del pro- 
yecto, y, si se aplica adecuadamente, debe reducir los 
riesgos antes de que se conviertan en problemáticos. 


Modelos evolutivas como el modelo en espiral, son 
apropiados, particularmente, pora el desorrollo de 
sistemos orientados a objetos. Paro más detalles, vénse 
la Parte cuarta, 


Pero al igual que otros paradigmas, el modelo en 
espiral no es la panacea. Puede resultar difícil conven- 
cer a grandes clientes (particularmente en situaciones 
bajo contrato) de que el enfoque evolutivo es controla- 
ble. Requiere una considerable habilidad para la eva- 
luación del riesgo, y cuenta con esta habilidad para el 
éxito. Si un riesgo importante no es descubierto y ges- 
tionado, indudablemente surgirán problemas. Final- 
mente, el modelo no se ha utilizado tanto como los 
paradigmas lineales secuenciales o de construcción de 
prototipos. Todavía tendrán que pasar muchos años antes 
de que se determine con absoluta certeza la eficacia de 
este nuevo e importante paradigma. 


2.7.3. El modelo espiral WINWIN 
(Victorias Victoria) 


El modelo en espiral tratado en la Seccion 2.7.2 sugie- 
re una actividad del marco de trabajo que aborda la 
comunicación con el cliente. El objetivo de esta activi- 
dad es mostrar los requisitos del cliente. En un contex- 
to ideal, el desarrollador simplemente pregunta al cliente 
lo que se necesita y el cliente proporciona detalles sufi- 
cientes para continuar. Desgraciadamente, esto rara- 
mente ocurre. En realidad el cliente y el desarrollador 
entran en un proceso de negociación, donde el cliente 
puede ser preguntado para sopesarla funcionalidad,ren- 
dimiento, y otros productos o características del siste- 
ma frente al coste y al tiempo de comercialización. 


pa 


la obtención de requisitosdel software requiereuna 
negociación. Tiene éxito cuando ambas partes «ganan». 


Las mejores negociaciones se esfuerzan en obtener 
«victoria-victoria». Esto es, el cliente gana obteniendo 
el producto o sistema que satisface la mayor parte de 
sus necesidades y el desarrollador gana trabajando para 
conseguir presupuestos y lograr una fecha de entrega 
realista. 


7 Hay docenas de libros escritos sobre habilidades en la negocia- 
ción [p. ej.,[FIS91], [DON96], [FAR97]].Es una de las cosas mas 
importantes que un ingeniero o gestorjoven (oviejo) puede apren- 
der. Lea uno. 
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El modelo en espiral WINWIN de Boehm [BOE98] 
define un conjunto de actividades de negociación al prin- 
cipio de cada paso alrededor de la espiral. Más que una 
simple actividad de comunicacióncon el cliente, se defi- 
nen las siguientes actividades: 

1. Identificación del sistema o subsistemas clave de los 
«directivos»", 

2. Determinación de las «condiciones de victoria» de 
los directivos. 

3. Negociación de las condiciones de «victoria» de los 
directivos para reunirlas en un conjunto de condi- 
ciones «victoria-victoria» para todos los afectados 
(incluyendo el equipo del proyecto de software). 


Habilidades de negociación 


Conseguidos completamente estos pasos iniciales se 
logra un resultado «victoria-victoria», que será el crite- 
rio clave para continuar con la definición del sistema y 
del software. El modelo en espiral WINWIN se ilustra 
en la Figura 2.9. 


2. Identificar las 
condiciones 
de victoria 


3a. Reunir las condiciones 

de victoria. 

¿ 3b. Establecer los objetivos, 
. restricciones y alternativas 


del siguiente nivel. 
para los AN 
directivos. f An 
LOA Evaluar las alternativas 


.. Gel producto y del procesc 
y resolución de riesgos. 


e 


E e: 


sl 


' De 
7. Revistón 


y comentarios.  - -* 5 dota , 
Pi 5. Definir el siguiente nivel 
6. Validar las ' del producto y del proceso, 
definiciones incluyendo particiones. 


del producto 
y del proceso. 


FIGURA 2.9. El modelo en espiral WINWIN [BOE98]. 


Además del énfasis realizado en la negociación ini- 
cial, el modelo en espiral WINWIN introduce tres hitos 
en el proceso, llamados puntos de fijación [BOE96], 
que ayudan a establecer la completitud de un ciclo alre- 
dedor de la espiral y proporcionan hitos de decisión 
antes de continuar el proyecto de software. 

En esencia, los puntos de fijación representan tres 
visiones diferentes del progreso mientras que el pro- 


8 Un directivo es alguien en la organización que tiene un interés 
directo, por el negocio, en el sistema o producto a construir y puede 
ser premiado por un resultado con éxito o criticado si el esfuerzo 
falla. 
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yecto recorre la espiral. El primer punto de fijación, 
llamado objetivos del ciclo de vida (OCV), define un 
conjunto de objetivos para cada actividad principal 
de ingeniería del software. Como ejemplo, de una par- 
te de OCV, un conjunto de objetivos asociados a la 
definición de los requisitos del producto/sistema del 
nivel más alto. El segundo punto de fijación, llama- 
do arquitectura del ciclo de vida (ACV), establece los 
objetivos que se deben conocer mientras que se defi- 
ne la arquitectura del software y el sistema. Como 
ejemplo, de una parte de la ACV, el equipo del pro- 
yecto de software debe demostrar que ha evaluado la 
funcionalidad de los componentes del software reuti- 
lizables y que ha considerado su impacto en las deci- 
siones de arquitectura. La capacidad operativa inicial 
(COJ) es el tercer punto de fijación y representa un 
conjunto de objetivos asociados a la preparación del 
software para la instalación/distribución, preparación 
del lugar previamente a la instalación, y la asistencia 
precisada de todas las partes que utilizará o manten- 
drá el software. 


2.7.4, El modelo de desarrollo concurrente 


Davis y Sitaram [DAV94] han descrito el modelo de 
desarrollo concurrente, llamado algunas veces inge- 
niería concurrente, de la forma siguiente: 


Los gestores de proyectos que siguen los pasos del estado 
del proyecto en lo que se refiere a las fases importantes [del 
ciclo de vida clásico] no tienen idea del estado de sus proyec- 
tos. Estos son ejemplos de un intento por seguir los pasos extre- 
madamente complejos de actividades mediante modelos 
demasiado simples. Tenga en cuenta que aunque un proyecto 
[grande]esté en la fase de codificación, hay personal de ese pro- 
yecto implicado en actividades asociadas generalmente a muchas 
fases de desarrollo simultáneamente. Por ejemplo, ... El perso- 
nal está escribiendo requisitos, diseñando, codificando, hacien- 
do pruebas y probando la integración [todo al mismo tiempo]. 
Los modelos de procesos de ingeniería del software de Humph- 
rey y Kellner [HUM89, KEL89] han mostrado la concurrencia 
que existe para actividades que ocurren durante cualquier fase. 
El trabajo más reciente de Kellner [KEL91] utiliza diagramas 
de estado [una notación que representa los estados de un pro- 
ceso] para representar la relación concurrente que existe entre 
actividades asociadas a un acontecimiento específico (por ejem- 
plo: un cambio de requisitos durante el último desarrollo), pero 
falla en capturar la riqueza de la concurrencia que existe en todas 
las actividades de desarrollo y de gestión del software en un 
proyecto... La mayoría de los modelos de procesos de desarro- 
llo del software son dirigidos por el tiempo; cuanto más tarde 
sea, más atrás se encontrará en el proceso de desarrollo. [Un 
modelo de proceso concurrente] está dirigido por las necesida- 


9 Se debería destacar que el análisis y el diseño son tareas comple- 
jas que requieren un estudio sustancial. Las Partes 111 y Iv del libro 


consideran estos temas con más detalle. 


10 Uh estado es algún modo externamente observable del compor- 
tamiento. 
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des del usuario, las decisiones de la gestión y los resultados de 
las revisiones. 


El modelo de proceso concurrente se puede repre- 
sentar en forma de esquema como una serie de acti- 
vidades técnicas importantes, tareas y estados 
asociados a ellas. Por ejemplo, la actividad de inge- 
niería definida para el modelo en espiral (Sección 
2.7.2), se lleva a cabo invocando las tareas siguien- 
tes: modelado de construcción de prototipos y/o aná- 
lisis, especificación de requisitos y diseño". 

La Figura 2.10 proporciona una representación esque- 
mática de una actividad dentro del modelo de proceso 
concurrente. La actividad — análisis —se puede encon- 
trar en uno de los estados"" destacados anteriormente en 
cualquier momento dado. De forma similar, otras acti- 
vidades (por ejemplo: diseño o comunicación con el 
cliente) se puede representar de una forma análoga. 
Todas las actividades existen concurrentemente, pero 
residen en estados diferentes. Por ejemplo, al principio 
del proyecto la actividad de comunicación con el clien- 
te (no mostrada en la figura) ha finalizado su primera 
iteración y está en el estado de cambios,en espera. La 
actividad de análisis (que estaba en el estado ninguno 
mientras que se iniciaba la comunicación inicial con el 
cliente) ahora hace una transición al estado bajo desa- 
rrollo. Sin embargo, si el cliente indica que se deben 
hacer cambios en requisitos, la actividad análisis cam- 
bia del estado bajo desarrollo al estado cambios en 
espera. 

El modelo de proceso concurrente define una serie 
de acontecimientos que dispararán transiciones de 
estado a estado para cada una de las actividades de la 
ingeniería del software. Por ejemplo, durante las pri- 
meras etapas del diseño, no se contempla una incon- 
sistencia del modelo de análisis. Esto genera la 
corrección del modelo de análisis de sucesos, que dis- 
parará la actividad de análisis del estado hecho al 
estado cambios en espera. 

El modelo de proceso concurrente se utiliza a menu- 
do como el paradigma de desarrollo de aplicacionesclien- 
te/servidor”' (Capítulo 28). Un sistema cliente/servidor 
se compone de un conjunto de componentes funciona- 
les. Cuando se aplica a cliente/servidor, el modelo de pro- 
ceso concurrente define actividadesen dos dimensiones 
[SHE94]: una dimensión de sistemas y una dimensiónde 
componentes. Los aspectos del nivel de sistemas se afron- 
tan mediante tres actividades: diseño, ensamblaje y uso. 


11 En aplicaciones cliente/servidor, la funcionalidad del software se 
divide entre clientes (normalmente PCs) y un servidor (una compu- 
tadora más potente) que generalmente mantiene una base de datos 
centralizada. 
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La dimensión de componentes se afronta con dos activi- 
dades: diseño y realización. La concurrencia se logra de 
dos formas: (1) las actividades de sistemas y de compo- 
nentes ocurren simultáneamente y pueden modelarsecon 
el enfoque orientado a objetos descrito anteriormente; (2) 
una aplicación cliente/servidor típica se implementacon 
muchos componentes, cada uno de los cuales se pueden 
diseñar y realizar concurrentemente. En realidad, el mode- 
lo de proceso concurrentees aplicable a todo tipo de desa- 
rrollo de software y proporciona una imagen exacta del 
estado actual de un proyecto. 


Actividad de análisi 


Ba aJO 
desarrollo 
espera 


a 


Ser 


FIGURA 2.10. Un elemento del modelo de proceso concurrente. 


DD 


Reperesenia un estado de 
una actividad de ingeniería 
del software. 


Las tecnologías de objetos (4.* Parte de este libro) pro- 
porcionan el marco de trabajo técnico para un modelo 
de proceso basado en componentes para la ingeniería 
del software. El paradigma orientado a objetos enfati- 
za la creación de clases que encapsulan tanto los datos 
como los algoritmos que se utilizan para manejar los 
datos. Si se diseñan y se implementan adecuadamente, 
las clases orientadas a objetos son reutilizables por las 
diferentes aplicacionesy arquitecturasde sistemas basa- 
dos en computadora. 
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FIGURA 2.11. Desarrollo basado en componentes. 


El modelo de desarrollo basado en componentes (Fig. 
2.11) incorpora muchas de las características del mode- 
lo en espiral. Es evolutivo por naturaleza [NIE92], y exi- 
ge un enfoque iterativo para la creación del software. 
Sin embargo, el modelo de desarrollo basado en com- 
ponentes configura aplicaciones desde componentes pre- 
parados de software (llamados «clases» en la Fig. 2.11). 


La tecnología resaltada para el DBC.se trata en lo Porte 
cuorta de este libro. 

En el Copítulo 27 se presenta un estudio más detallado 
del proceso DBC. 
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La actividad de la ingeniería comienza con la iden- 
tificación de clases candidatas. Esto se lleva a cabo exa- 
minando los datos que se van a manejar por parte de la 
aplicación y el algoritmo que se va a aplicar para con- 
seguir el tratamiento”. Los datos y los algoritmos corres- 
pondientes se empaquetan en una clase. 

Las clases creadas en los proyectos de ingeniería del 
software anteriores, se almacenan en una biblioteca de 
clases o diccionario de datos (repository) (Capítulo 31). 
Una vez identificadas las clases candidatas, la biblioteca 
de clases se examina para determinar si estas clases ya 
existen. En caso de que así fuera, se extraen de la biblio- 
teca y se vuelven a utilizar. Si una clase candidata no resi- 
de en la biblioteca, se aplican los métodos orientados a 
objetos (Capítulos 2 1-23).Se compone asíla primera ite- 
ración de la aplicación a construirse, mediante las clases 
extraídas de la biblioteca y las clases nuevas construidas 
para cumplir las necesidades Únicas de la aplicación. El 
flujo del proceso vuelve a la espiral y volverá a introdu- 
cir por último la iteración ensambladora de componen- 
tes a través de la actividad de ingeniería. 


El modelo de desarrollo basado en componentes con- 
duce a la reutilización del software, y la reutilización pro- 
porciona beneficios a los ingenieros de software. Según 
estudios de reutilización, QSM Associates, Inc. informa 
que el ensamblaje de componentes lleva a una reducción 
del 70 por 100 de tiempo de ciclo de desarrollo, un 84 
por 100 del coste del proyecto y un índice de producti- 
vidad del 26.2, comparado con la norma de industria del 

16.9[Y0U94]. Aunque estosresultados están en función 

de la robustez de la biblioteca de componentes, no hay 
duda de que el ensamblaje de componentes proporciona 
ventajas significativaspara los ingenieros de software. 


El proceso unificado de desarrollo de software 
[JAC99] representa un número de modelos de desarro- 
llo basados en componentes que han sido propuestos en 


12 Esta es una descripción simplificada de definición de clase. Para 
un estudio más detallado, consulte el Capítulo 20. 
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la industria. Utilizando el Lenguaje de Modelado Uni- 
ficado (UML), el proceso unificado define los compo- 
nentes que se utilizarán para construir el sistema y las 
interfaces que conectarán los componentes. Utilizando 
una combinacion del desarrollo incremental e iterativo, 
el proceso unificado define la función del sistema apli- 
cando un enfoque basado en escenarios (desde el pun- 
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to de vista del usuario). Entonces acopla la función con 
un marco de trabajo arquitectónico que identifica la for- 
ma que tomará el software. 


En los Capítulos 21 y 22 se trata UML con más detalle. 


El modelo de métodos formales comprende un conjun- 
to de actividades que conducen a la especificación mate- 
mática del software de computadora. Los métodos 
formales permiten que un ingeniero de software espe- 
cifique, desarrolle y verifique un sistema basado en com- 
putadora aplicando una notación rigurosa y matemática. 
Algunas organizaciones de desarrollo del software 
actualmente aplican una variación de este enfoque, lla- 
mado ingeniería del software de sala limpia [MIL87, 
DYE92]. 


Referencia cruzada 


los métodosformales se tratan en los Capítulos23 y 26. 


Cuando se utilizan métodos formales (Capítulos 25 
y 26) durante el desarrollo, proporcionan un mecanis- 
mo para eliminar muchos de los problemas que son difí- 
ciles de superar con paradigmas de la ingeniería del 
software. La ambigijedad, lo incompleto y la inconsis- 
tencia se descubren y se corrigen más fácilmente —no 
mediante un revisión a propósito para el caso, sino 
mediante la aplicación del análisis matemático —. Cuan- 
do se utilizan métodos formales durante el diseño, sir- 
ven como base'para la verificación de programas y por 


consiguiente permiten que el ingenierodel software des- 
cubra y corrija errores que no se pudieron detectar de 
otra manera. 

Aunque todavía no hay un enfoque establecido, los 
modelos de métodos formales ofrecen la promesa de un 
software libre de defectos. Sin embargo, se ha hablado 
de una gran preocupación sobre su aplicabilidad en un 
entorno de gestión: 


1, El desarrollo de modelos formales actualmente es 
bastante caro y lleva mucho tiempo. 


2. Se requiere un estudio detallado porque pocos res- 
ponsables del desarrollo de software tienen los ante- 


cedentes necesarios para aplicar métodos formales. 

. Es difícil utilizar los modelos como un mecanismo 
de comunicación con clientes que no tienen muchos 
conocimientos técnicos. 


No obstante es posible que el enfoque a través de 
métodos formales tenga más partidarios entre los desa- 
rrolladores del software que deben construir software 
de mucha seguridad (por ejemplo: los desarrolladores 
de aviónica y dispositivos médicos), y entre los desa- 
rrolladores que pasan grandes penurias económicas al 
aparecer errores de software. 


El término técnicas de cuarta generación (T4G) abarca 
un amplio espectro de herramientas de software que tie- 
nen algo en común: todas facilitan al ingeniero del soft- 
ware la especificación de algunas características del 
software a alto nivel. Luego, la herramienta genera auto- 
máticamente el código fuente basándose en la especifi- 
cación del técnico. Cada vez parece más evidente que 
cuanto mayor sea el nivel en el que se especifique el 
software, más rápido se podrá construir el programa. El 
paradigma T4G para la ingeniería del software se orien- 
ta hacia la posibilidad de especificar el software usan- 
do formas de lenguaje especializado o notaciones 
gráficas que describa el problema que hay que resolver 
en términos que los entienda el cliente. Actualmente, 
un entorno para el desarrollo de software que soporte 
el paradigma T4G puede incluir todas o algunas de las 
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siguientes herramientas: lenguajes no procedimentales 
de consulta a bases de datos, generación de informes, 
manejo de datos, interacción y definición de pantallas, 
generación de códigos, capacidades gráficas de alto nivel 
y capacidades de hoja de cálculo, y generación auto- 
matizada de HTML y lenguajes similaresutilizados para 
la creación de sitios web usando herramientas de soft- 
ware avanzado. Inicialmente, muchas de estas herra- 
mientas estaban disponibles, pero sólo para ámbitos de 
aplicación muy específicos, pero actualmente los entor- 
nos T4G se han extendido a todas las categorías de apli- 
caciones del software. 

Al igual que otros paradigmas, T4G comienza con 
el paso de reunión de requisitos. Idealmente, el cliente 
describe los requisitos, que son, a continuación, tradu- 
cidos directamente a un prototipo operativo. Sinembar- 
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go, en la práctica no se puede hacer eso. El cliente pue- 
de que no esté seguro de lo que necesita; puede ser ambi- 
guo en la especificaciónde hechos que le son conocidos, 
y puede que no sea capaz O no esté dispuesto a especi- 
ficar la información en la forma en que puede aceptar 
una herramienta T4G. Por esta razón, el diálogo clien- 
te-desarrollador descrito por los otros paradigmas sigue 
siendo una parte esencial del enfoque F4G, 


Consuoh 


Incluso cuando utilice una 746, tiene que destacar 
claramente la ingeniería dlel software haciendo el análisis, 
el diseño y los pruebas. 


Para aplicaciones pequeñas, se puede ir directamen- 
te desde el paso de recolección de requisitos al paso de 
implementación, usando un lenguaje de cuarta genera- 
ción no procedimental (L4G) o un modelo comprimi- 
do de red de iconos gráficos. Sin embargo, es necesario 
un mayor esfuerzo para desarrollar una estrategia de 
diseño para el sistema, incluso si se utiliza un LAG. El 
uso de T4G sin diseño (para grandes proyectos) causa- 
rá las mismas dificultades (poca calidad, mantenimien- 
to pobre, mala aceptación por el cliente) que se 
encuentran cuando se desarrolla software mediante los 
enfoques convencionales. 

La implementación mediante L4G permite, al que 
desarrolla el software, centrarse en la representación de 
los resultados deseados, que es lo que se traduce auto- 
máticamente en un código fuente que produce dichos 
resultados. Obviamente, debe existir una estructura de 
datos con información relevante y a la que el L4G pue- 
da acceder rápidamente. 

Para transformar una implementación T4G en un 
producto, el que lo desarrolla debe dirigir una prueba 
completa, desarrollar con sentido una documentación 
y ejecutar el resto de las actividades de integración que 
son también requeridas requeridas por otros paradig- 
mas de ingeniería del software. Además, el software 
desarrollado con T4G debe ser construido de forma 


que facilite la realización del mantenimiento de forma 
expeditiva. 

Al igual que todos los paradigmas del software, el 
modelo T4G tiene ventajase inconvenientes.Los defen- 
sores aducen reducciones drásticasen el tiempo de desa- 
rrollo del software y una mejora significativa en la 
productividad de la gente que construye el software. 
Los detractores aducen que las herramientas actuales 
de T4G no son más fáciles de utilizar que los lenguajes 
de programación, que el código fuente producido por 
tales herramientas es «ineficiente» y que el manteni- 
miento de grandes sistemas de software desarrollados 
mediante T4G es cuestionable. 

Hay algún mérito en lo que se refiere a indicaciones 
de ambos lados y es posible resumir el estado actual de 
los enfoques de T4G: 


1, El uso de T4G es un enfoque viable para muchas de 
las diferentes áreas de aplicación.Junto con las herra- 
mientas de ingeniería de software asistida por com- 
putadora (CASE) y los generadores de código, T4G 
ofrece una solución fiable a muchos problemas del 
software. 

. Los datos recogidos en compañías que usan T4G 
parecen indicar que el tiempo requerido para produ- 
cir software se reduce mucho para aplicaciones 
pequeñas y de tamaño medio, y que la cantidad de 
análisis y diseño para las aplicaciones pequeñas tam- 
bién se reduce. 

. Sin embargo, el uso de T4G para grandes trabajos de 
desarrollo de software exige el mismo o más tiempo 
de análisis, diseño y prueba (actividades de ingenie- 
ría del software), para lograr un ahorro sustancial de 
tiempo que puede conseguirse mediante la elimina- 
ción de la codificación. 


Resumiendo, las técnicas de cuarta generación ya se 
han convertido en una parte importante del desarrollo 
de software. Cuando se combinan con enfoques de 
ensamblaje de componentes (Sección 2.8), el paradig- 
ma T4G se puede convertir en el enfoque dominante 
hacia el desarrollo del software. 


Los modelos de procesos tratados en las secciones ante- 
riores se deben adaptar para utilizarse por el equipo del 
proyecto del software. Para conseguirlo, se han desarro- 
llado herramientas de tecnología de procesos para ayudar 
a organizaciones de software a analizar los procesos actua- 
les, organizar tareas de trabajo, controlar y supervisar el 
progreso y gestionar la calidad técnica [BAN9S5]. 

Las herramientas de tecnología de procesos permi- 
ten que una organización de software construya un 
modelo automatizado del marco de trabajo común de 
proceso, conjuntos de tareas y actividades de protec- 
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ción tratadas en la Sección 2.3. El modelo, presentado 
normalmente como una red, se puede analizar para deter- 
minar el flujo de trabajo típico y para examinar estruc- 
turas alternativas de procesos que pudieran llevar a un 
tiempo o coste de desarrollo reducidos. 

Una vez que se ha creado un proceso aceptable, se 
pueden utilizar otras herramientas de tecnología de pro- 
cesos para asignar, supervisar e incluso controlar todas 
las tareas de ingeniería del software definidas como par- 
te del modelo de proceso. Cada uno de los miembros 
de un equipo de proyecto de softwarepuede utilizar tales 
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herramientas para desarrollar una lista de control de 
tareas de trabajo a realizarse, productos de trabajo a pro- 
ducirse, y actividades de garantía de calidad a condu- 
cirse. La herramienta de tecnología de proceso también 
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se puede utilizar para coordinar el uso de otras herra- 
mientas de ingeniería del software asistida por compu- 
tadora (Capítulo 3 1) adecuadas para una tarea de trabajo 
en particular. 


Si el proceso es débil, el producto final va a sufrir indu- 
dablemente. Aunque una dependencia obsesiva en el 
proceso también es peligrosa. En un breve ensayo, Mar- 
garet Davis [DAV95] comenta la dualidad producto y 
proceso: 


Cada diez años o cinco aproximadamente, la comunidad del soft- 
ware vuelve a definir «el problema» cambiandoel foco de los aspec- 
tos de producto a los aspectos de proceso. Por consiguiente, se han 
abarcado lenguajes de programación estructurados(producto)segui- 
dos por métodos de análisis estructurados (proceso) seguidos a su 
vez por encapsulaciónde datos (producto) y después por el énfasis 
actual en el Modelo Madurez de Capacidad de Desarrollo del soft- 
ware del Instituto de ingeniería de software (proceso). 


Mientras que la tendencia natural de un péndulo es parar en medio 
de dos extremos, el enfoque de la comunidad del software cambia 
constantemente porque se aplica una fuerza nueva cuando falla el 
último movimiento. Estos movimientos son perjudicialespor símis- 
mos y en sí mismos porque confunden al desarrollador del softwa- 
re medio cambiando radicalmentelo que significarealizarel trabajo, 
que por sí mismo lo realiza bien. Los cambios tampoco resuelven 
«el problema», porque están condenados al fracaso siempre que el 
producto y el proceso se traten como si formasen una dicotomía en 
lugar de una dualidad. 


ollo sin pensar y se aplica 
ente, el proceso puede convertirse] en 


En la comunidad científicahay un precedente que se adelanta a 
las nociones de dualidad cuando contradicciones en observaciones 
no se pueden explicar completamente con una teoría competitiva u 
otra. La naturaleza dual de la luz, que parece ser una partícula y una 
onda al mismo tiempo, se ha aceptado desde los años veinte cuan- 
do Louis de Broglie lo propuso. Creo que las observaciones que se 
hacen sobre los mecanismos del software y su desarrollo demues- 
tran una dualidad fundamental entre producto y proceso. Nunca se 
puede comprender el mecanismo completo, su contexto, uso, signi- 
ficado y valor si se observa sólo como un proceso o sólo como un 
producto... 


Toda actividad humana puede ser un proceso, pero cada uno de 
nosotros obtiene el sentido de autoestima ante esas actividades que 
producen una representación o ejemplo que más de una persona 
puede utilizar o apreciar, una u otra vez, o en algún otro contexto 
no tenido en cuenta. Es decir, los sentimientos de satisfacción se 
obtienen por volver a utilizar nuestros productos por nosotros mis- 
mos O por otros. 


Así pues, mientras que la asimilación rápida de los objetivos 
de reutilización en el desarrollo del software aumenta potencial- 
mente la satisfacción que los desarrolladores obtienen de su tra- 
bajo, esto incrementa la urgencia de aceptar la dualidad producto 
y proceso. Pensar en un mecanismo reutilizable como el único 
producto o el único proceso, bien oscurece el contexto y la forma 
de utilizarlo, o bien el hecho de que cada utilización elabora el 
producto que a su vez se utilizará como entrada en alguna otra 
actividad de desarrollo del software. Elegir un método sobre otro 
reduce enormemente las oportunidades de reutilización y de aquí 
que se pierda la oportunidad de aumentar la satisfacción ante el 
trabajo. 


se vuelve creativa si el autor se 
cerlo bien o de hacerlo mejor. 


Las personas obtienen tanta satisfacción (o más) del 
proceso creativo que del producto final. Un artista dis- 
fruta con las pinceladas de la misma forma que disfru- 
ta del resultado enmarcado. Un escritor disfruta con la 
búsqueda de la metáfora adecuada al igual que con el 
libro final. Un profesional creativo del software debe- 
ría también obtener tanta satisfacción de la programa- 
ción como del producto final. 

El trabajo de los profesionales del software cambia- 
rá en los próximos años. La dualidad de producto y pro- 
ceso es un elemento importante para mantener ocupada 
a la gente creativa hasta que se finalice la transición de 
la programación a la ingeniería del software. 


La ingeniería del software es una disciplina que inte- 
gra procesos, métodos y herramientas para el desa- 
rrollo del software de computadora. Se han propuesto 
varios modelos de procesos para la ingeniería del soft- 
ware diferentes, cada uno exhibiendo ventajas e incon- 
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venientes, pero todos tienen una serie de fases gené- 
ricas en común. En el resto de este libro se consideran 
los principios, conceptos y métodos que permiten lle- 
var a cabo el proceso que se llama ingeniería del soft- 
ware. 
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2.1. La Figura 2.1 sitúa las tres capas de ingeniería del soft- 
ware encima de la capa titulada «enfoque de calidad». Esto 
implica un programa de calidad tal como Gestión de Cali- 
dad Total. Investigue y desarrolle un esquema de los prin- 
cipios clave de un programa de Gestión de Calidad Total. 
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2.2. ¿Hay algún caso en que no se apliquen fases genéricas 
del proceso de ingeniería del software? Sies así, descríbalo. 
2.3. El Modelo Avanzado de Capacidad del SEÍ es un docu- 
mento en evolución. Investigue y determine si se han aña- 
dido algunas ACP nuevas desde la publicación de este libro. 
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2.4, El modelo del caos sugiere que un bucle de resolución de 
problemas se pueda aplicar en cualquier grado de resolución. 
Estudie la forma en que se aplicaría el bucle (1) para com- 
prender los requisitos de un producto de tratamiento de texto; 
(2) para desarrollarun componente de corrección ortográfica 
y gramática avanzado para el procesador de texto; (3) para 
generar el código para un módulo de programa que determi- 
ne el sujeto, predicado y objeto de una oración en inglés. 


25. ¿Qué paradigmas de ingenieríadel softwarede los presen- 
tados en este capítulopiensa que sería el más eficaz? ¿Por qué? 


2.6. Proporcione cinco ejemplos de proyectos de desarrollo 
del software que sean adecuados para construir prototipos. 
Nombre dos o tres aplicaciones que fueran más difíciles para 
construir prototipos. 


2.7. El modelo DRA a menudo se une a herramientas CASE. 
Investigue la literatura y proporcione un resumen de una herra- 
mienta típica CASE que soporte DRA. 
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2.8. Proponga un proyecto específicode software que sea ade- 
cuado para el modelo incremental. Presente un escenario para 
aplicar el modelo al software. 


2.9. A medida que vaya hacia afuera por el modelo en espiral, 
¿qué puede decir del softwareque se está desarrollando o man- 
teniendo? 


2.10. Muchas personas creen que la Única forma en la que se 
van a lograr mejoras de magnitud en la calidad del software y 
en suproductividad es a través del desarrollo basado en com- 
ponentes. Encuentre tres o cuatro artículos recientes sobre el 
asunto y resúmalos para la clase. 


2.11. Describa el modelo de desarrollo concurrente con sus 
propias palabras. 


2.12. Proporcione tres ejemplos de técnicas de cuarta genera- 
ción. 


2.13. ¿Qué es más importante, el producto o el proceso? 


El estado actual del arte en la ingeniería del software se puede 
determinar mejora partir de publicacionesmensuales tales como 
IEEE Software, Computer e IEEE Transactions on Software 
Engineering. Periódicos sobre la industriatales como Applica- 
tion Developement Trends, Cutter! T Journal y Software Deve- 
lopement a menudo contienen artículossobretemas de ingeniería 
del software. La disciplina se «resume» cada año en el Proce- 
eding of the International Conference on Software Engineering, 
promocionado por el IEEE y ACM y tratado en profundidad en 
periódicos comoACM Transactions on Software Engineering 
and Methodology, ACM Software Engineering Notes y Annals 
of Software Engineering. 

Se han publicado muchos libros de ingeniería del softwa- 
re en los últimos años. Algunos presentan una visión general 
del proceso entero mientras que otros se dedican a unos pocos 
temas importantes para la exclusión de otros. Las siguientes 
son tres antologías que abarcan algunos temas importantes 
de ingeniería del software: 

Keyes, J. (ed.), Software Engineering Productivity Hand- 
book, McGraw-Hill, 1993. 

McDermid, J. (ed.), Software Engineer's Reference Book, 
CRC Press, 1993. 

Marchiniak, J.J. (ed.), Encyclopedia of Software Engine- 
ering, Wiley, 1994, 

Gautier (Distributed Engineering of Software, Prentice- 
Hall, 1996)proporciona sugerencias y directrices para orga- 
nizaciones que deban desarrollar software en lugares 
geográficamentedistantes. 

En la parte más brillante del libro de Robert Glass (Soft- 
ware Conflict, Yourdon Press, 1991) se presentan ensayos 
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controvertidos y amenos sobre el software y el proceso de la 
ingeniería del software. Pressman y Herron (SoftwareShock, 
Dorset House, 1991) consideran el software y su impacto 
sobre particulares, empresas y el gobierno. 

El Instituto de ingeniería del software (118 localizado en 
la Universidad de Carnegie-Mellon) ha sido creado con la 
responsabilidad de promocionar series monográficas sobre 
la ingeniería del software. Los profesionales académicos, 
en la industria y el gobierno están contribuyendo con nue- 
vos trabajos importantes. El Consorcio de Productividad del 
Software dirige una investigación adicional de ingeniería 
de software. 

En la última década se ha publicado una gran variedad de 
estándares y procedimientos de ingeniería del software.El IEEE 
Software Engineering Standards contiene muchos estándares 
diferentes que abarcan casi todos los aspectos importantes de 
la tecnología. Las directrices ISO 9000-3 proporcionan una 
guía para las organizaciones de software que requieren un regis- 
tro en el estándar de calidad ISO 9001. Otros estándares de 
ingeniería del software se pueden obtener desde el MOD, la 
Autoridad Civil de Aviación y otras agencias del gobierno y 
sin ánimo de lucro. Fairclough (Software Engineering Guides, 
Prentice-Hall, 1996) proporciona una referencia detallada de 
los estándares de ingeniería del software producidos por Euro- 
pean Space Agency (ESA). 

En internet se dispone de una gran variedad de fuentes de 
información sobre la ingeniería del software y del proceso de 
software. Se puede encontrar una lista actualizada con refe- 
rencias a sitios (páginas) web que son relevantes para el pro- 
ceso del software en http://www.pressman5.com. 
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PARTE 


GESTION DE PROYECTOS 
DE SOFTWARE 


N esta parte de Ingeniería del Software: Un erfoque Práctico, estudiamos 

las técnicas de gestión necesarias para planificar, organizar, supervisar 

y controlar proyectos de software. En los capítulos que vienen a conti- 
nuación, obtendremos respuestas a las siguientes cuestiones: 


*...  ¿Cómose debe gestionar el personal, el proceso y el problema durante un 
proyecto de software? 


+  ¿Quéson las métricas de software y cómo pueden emplearse para gestio- 
nar un proyecto de software y el proceso del software? 


. ¿Cómo genera un equipo de software estimaciones fiables del esfuerzo, 
costes y duración del proyecto? 


. ¿Qué técnicas pueden emplearse para evaluar formalmente 105 ESAS 
que pueden tener impacto en el éxito del proyecto? . 


. ¿Cómo selecciona un gestor de proyectos de software el conjunto de tareas ; 
del proyecto de ingeniería de software? 


e ¿Cómo se crea la planificación temporal de un proyecto? 

+ ¿Cómo se define la calidad para que pueda ser controlada? 

e  ¿Quéesla garantía de calidad del software? 

e ¿Por qué son tan importantes las revisiones técnicas formales? 


e ¿Cómo se gestionan los cambios durante el desarrollo de AS de com- 
putadora y después de entregarlo al cliente? 


Una vez que se haya dado respuesta a estas cuestiones, estará mejor prepa- 
rado para gestionar proyectos de software de manera que entregue un producto 
de alta calidad puntualmente. 
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CONCEPTOS SOBRE GESTION 
DE PROYECTOS 


N el prefacio de su libro sobre gestión de proyectos de software, Meiler Page-Jones 

[PAG85] dice una frase que pueden corroborar muchos asesores de ingeniería del soft- 
Ware: 

He visitado docenas de empresas, buenas y malas, y he observado a muchos administradores de proce- 

so de datos, también buenos y malos. Frecuentemente, he visto con horror cómo estos administradores lucha- 

ban inútilmente contra proyectos de pesadilla, sufriendo por fechas límite imposibles de cumplir, o que 


entregaban sistemas que decepcionaban a sus usuarios y que devoraban ingentes cantidades de horas de 
mantenimiento. 


Lo que describe Page-Jones son síntomas que resultan de una serie de problemas técnicos y 
de gestión. Sin embargo, si se hiciera una autopsia de cada proyecto, es muy probable que se 
encontrara un denominador común constante: una débil gestión. 

En este capítulo y en los seis que siguen consideraremos los conceptos clave que llevan a 
una gestión efectiva de proyectos de software. Este capítulo trata conceptos y principios bási- 
cos sobre gestión de proyectos de software. El Capítulo 4 presenta las métricas del proyecto y 
del proceso, la base para una toma de decisiones de gestión efectivas. Las técnicas que se emple- 
an para estimar los costes y requisitos de recursos y poder establecer un plan efectivo del pro- 
yecto se estudian en el Capítulo 5. Las actividades de gestión que llevan a una correcta 
supervisión, reducción y gestión del riesgo se presentan en el Capítulo 6. El Capítulo 7 estudia 
las actividades necesarias para definir las tareas de un proyecto y establecer una programación 
del proyecto realista. Finalmente, los Capítulos 8 y 9 consideran técnicas para asegurar la cali- 
dad a medida que se dirige un proyecto y el control de los cambios a lo largo de la vida de una 
aplicación. 


VISTAZO RÁPIDO 


ciendo puntos de control de calidad y 
estableciendo mecanismos para con- 
trolar y supervisar el trabajo definido 


nan la relación entre el negocio y los 
profesionales del software. 


¿Por qué es importante? La construc- 


¿Qué es? Aunque muchos de nosotros 
(en nuestros momentos más oscuros) - 
tomamos la visión de Dilbert sobre la 


«gestión», falta una actividad muy 
necesaria cuando se construyen pro- 
ductos y sistemas basados en compu- 
tadoras. La gestión de proyectos 
implica la planificación, supervisión 
y control del personal, del proceso y 
de los eventos que ocurren mientras 
evoluciona el software desde la fase 
preliminar a la implementación ope- 
racional. 


¿Quién lo hace? Todos «gestionamos» 


de algún modo, pero el ámbito de las 
actividades de gestión varía en función 


de la persona que las realiza. Un inge- 
niero de software gestiona sus activi- 


dades del día a día, planificando, 
supervisando, Y controlando las tareas 
técnicas. Los gestores del proyecto pla- 
nifican, supervisan Y Controlan el tra- 
bajo de un equipo de ingenieros de 
software, Los gestores expertos coordi- 


ción de software de computadora es 
una empresa compleja, particular- 
mente si participa mucha gente, tra- 
bajando durante un periodo de tiempo 
relativamente largo. Esta es la razón 
por la cual los proyectos de software 
necesitan ser gestionados. 


¿Cuáles son los pasos? Comprender 


las cuatro «P's» —personal, producto, 
proceso y proyecto—. El personal 
debe estar organizado para desarro- 
llar el trabajo del software con efecti- 
vidad. La comunicación con el cliente 
debe ocurrir para que se comprendan 
el alcance del producto y los requisi- 
tos. Debe seleccionarse el proceso 
adecuado para el personal, y el pro- 
ducto. El proyecto debe planificarse 
estimando el esfuerzo y el tiempo 
para cumplir las tareas; definiendo 
los productos del trabajo, estable- 
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en la planificación. 


¿Cuál es el producto obtenido? Un 


plan de proyecto se realiza al comien- 
zo de las actividades de gestión. El 
plan define el proceso y las tareas a 
realizar el personal queréxlizazá el tra- 
bajo y los mecanismos para evaluar los 
riesgos, controlar el cambio y evaluar 
la calidad. 


¿Cómo puedo estar seguro de que 


lo he hecho correctamente? Nun- 
caestáscompletamente segurode que 
el plan de proyecto es correcto hasta 
que no has entregado un producto de 
alta calidad dentro del tiempo y del 
presupuesto. Sin embargo, un gestor 
de proyectos hace lo correcto cuando 
estimulaalpersonal para trabajar jun- 
tos como un equipo efectivo, centran- 
do suatención en las necesidades del 
cliente y en la calidad del producto. 
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La gestión eficaz de un proyecto de software se cen- 
tra en las cuatro P”s: personal, producto, proceso y 
proyecto. El orden no es arbitrario. El gestor que se 
olvida de que el trabajo de ingeniería del software es 
un esfuerzo humano intenso nunca tendrá éxito en la 
gestión de proyectos. Un gestor que no fomenta una 
minuciosa comunicación con el cliente al principio 
de la evolución del proyecto se arriesga a construir 
una elegante solución para un problema equivocado. 
El administrador que presta poca atención al proce- 
so corre el riesgo de arrojar métodos técnicos y herra- 
mientas eficaces al vacío. El gestor que emprende un 
proyecto sin un plan sólido arriesga el éxito del pro- 
ducto. 


3.1.1. Personal 


La necesidad de contar con personal para el desarrollo 
del software altamente preparado y motivado se viene 
discutiendo desde los años 60 (por ejemplo, [C0U80, 
WIT94, DEM98])). De hecho, el «factor humano» es tan 
importante que el Instituto de Ingeniería del Software 
ha desarrollado un Modelo de madurez de la capacidad 
de gestión de personal (MMCGP) «para aumentar la 
preparación de organizaciones del software para llevar 
a cabo las cada vez más complicadas aplicaciones ayu- 
dando a atraer, aumentar, motivar, desplegar y retener 
el talento necesario para mejorar su capacidad de desa- 
rrollo de software» [CUR94]. 


l capacidad de distintos 


El modelo de madurez de gestión de personal defi- 
ne las siguientes áreas clave prácticas para el personal 
que desarrolla software: reclutamiento, selección, ges- 
tión de rendimiento, entrenamiento, retribución, desa- 
rrollo de la carrera, diseño de la organización y del 
trabajo y desarrollo cultural y de espíritu de equipo. 

El MMCCP es compañero del modelo de madurez 
de la capacidad software (Capítulo 2), que guía a las 
organizacionesen la creación de un proceso de software 
maduro. Más adelante en este capítulo se consideran 
aspectos asociados a la gestión de personal y estructu- 
ras para proyectos de software. 
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3.1.2. Producto 


Antes de poder planificar un proyecto, se deberían esta- 
blecer los objetivos y el ámbito del producto*, se debe- 
rían considerar soluciones alternativas e identificar las 
dificultades técnicas y de gestión. Sin esta información, 
es imposible definir unas estimaciones razonables (y 
exactas) del coste; una valoración efectiva del riesgo, 
una subdivisión realista de las tareas del proyecto o una 
planificación del proyecto asequible que proporcione 
una indicación fiable del progreso. 


Referencia cruzada 


En el Capitulo 1 se trata una taxonomía de las áreas 
de aplicación que producenlos «productos» de software, 


El desarrolladorde software y el cliente deben reunir- 
se para definir los objetivos del producto y su ámbito. En 
muchos casos, esta actividad empieza como parte del pro- 
ceso de ingenieríadel sistema o del negocio (Capítulo 10) 
y continúa comoel primer paso en el análisis de los requi- 
sitos del software (Capítulo 11). Los objetivos identifican 
las metas generales del proyecto sin considerar cómo se 
conseguirán (desde el punto de vista del cliente). 

El ámbito identifica los datos primarios, funciones y 
comportamientos que caracterizan al producto, y, más 
importante, intenta abordar estas características de una 
manera cuantitativa. 

Una vez que se han entendidolos objetivos y el ámbi- 
to del producto, se consideran soluciones alternativas. 


3.1.3. Proceso 


Un proceso de software (Capítulo 2) proporciona la 
estructura desde la que se puede establecer un detalla- 
do plan para el desarrollo del software. Un pequeño 
número de actividades estructurales se puede aplicar a 
todos los proyectos de software, sin tener en cuenta su 
tamaño o complejidad. Diferentes conjuntos de tareas 
— tareas, hitos, productos del trabajo y puntos de garan- 
tía de calidad — permiten a las actividades estructura- 
les adaptarse a las características del proyecto de 
software y a los requisitos del equipo del proyecto. Final- 
mente, las actividades protectoras —+talescomo garan- 
tía de calidad del software, gestión de la configuración 
del software y medición — cubren el modelo de proce- 
so. Las actividades protectoras son independientes de 
las estructurales y tienen lugar a lo largo del proceso. 


1 En este contexto, el termino «producto» es usado para abarcar cual- 
quier software que será construido a petición de otros. Esto incluye 
no sólo productos de software, sino también sistemas basados en 
computadora, software empotrado y software de resolución de pro- 
blemas (por ejemplo, programas para la resolución de problemas 
científicos/de ingeniería). 
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las actividades estructurales se componende tareas, hitos, 
productos de trabajo y puntos de garantía de calidad. 


3.1.4, Proyecto 


Dirigimos los proyectos de software planificados y con- 
trolados por una razón principal -es la Única manera 
conocida de gestionar la complejidad —. Y todavía 
seguimos esforzándonos. En 1998, los datos de la indus- 
tria del software indicaron que el 26 por 100 de pro- 
yectos de software fallaron completamente y que el 46 


SOBRE GESTIÓN DE PROYECTOS 


LULA AU 


por 100 experimentaron un desbordamiento en la pla- 
nificación y en el coste [REE99]. Aunque la proporción 
de éxito para los proyectos de software ha mejorado un 
poco, nuestra proporción de fracaso de proyecto per- 
manece más alto del que debería ser”. 

Para evitar el fracaso del proyecto, un gestor de pro- 
yectos de software y los ingenieros de software que 
construyeron el producto deben eludir un conjunto de 
señales de peligro comunes; comprender los factores 
del éxito críticos que conducen a la gestión correcta del 
proyecto y desarrollar un enfoque de sentido común 
para planificar, supervisar y controlar el proyecto. Cada 
uno de estos aspectos se trata en la Sección 3.5 y en los 
capítulos siguientes. 


En un estudio publicado por el IEEE [CUR88] se les 
preguntó a los vicepresidentes ingenieros de tres gran- 
des compañías tecnológicas sobre el factor más impor- 
tante que contribuye al éxito de un proyecto de software. 
Respondieron de la siguiente manera: 


VP 1: Supongo que si tuviera que elegir lo más importante 
de nuestro entorno de trabajo, diría que no son las 
herramientas que empleamos, es la gente. 


VP 2: El ingrediente más importante que contribuyó al éxi- 
to de este proyecto fue tener gente lista ...pocas cosas 
más importan en mi opinión ... Lo más importante 
que se puede hacer por un proyecto es seleccionar el 
personal ...El éxito de la organización de desarrollo 
del software está muy, muy asociado con la habili- 
dad dereclutar buenos profesionales. 


:La única regla que tengo en cuanto a la gestión 
es asegurarme de que tengo buenos profesionales 
— genterealmente buena —, de que preparo bue- 
na gente y de que proporciono el entorno en el 
que los buenos profesionales puedan producir. 


gestionan sensiblemente 
rsonol a la lorga prosperarán. 
Tim Lister 


Ciertamente, éste es un testimonio convincente sobre 
la importancia del personal en el proceso de ingeniería 
del software. Y, sin embargo, todos nosotros, desde los 
veteranos vicepresidentes al más modesto profesional 
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del software, damos este aspecto por descontado. Los 
gestores argumentan (como el grupo anterior) que el 
personal es algo primario, pero los hechos desmienten 
a veces sus palabras. 

En esta sección examinamos los participantes que cola- 
boran en el proceso del software y la manera en que se 
organizan para realizar una ingeniería del Software eficaz. 


3.2.1. Los participantes 


El proceso del software (y todos los proyectos de soft- 
ware) lo componen participantes que pueden clasificarse 
en una de estas cinco categorías: 


1. Gestores superiores, que definen los aspectos de 
negocios que a menudo tienen una significativa 
influencia en el proyecto. 

. Gestores (técnicos )del proyecto, que deben planifi- 

car, motivar, organizar y controlar a los profesiona- 

les que realizan el trabajo de software. 

Profesionales, que proporcionan las capacidades téc- 

nicas necesarias para la ingeniería de un producto o 

aplicación. 


bed 


. Clientes, que especifican los requisitos para la inge- 
niería del software y otros elementos que tienen 
menor influencia en el resultado. 


Usuarios finales, que interaccionan con el software 
una vez que se ha entregado para la producción. 


Para ser eficaz, el equipo del proyecto debe organizarse 
de manera que maximice las habilidades y capacidades 
de cada persona. Y este es el trabajo deljefe del equipo. 


2 Dadas estas estadísticas,es razonable preguntarse cómo el impacto 
de las computadorascontinúa creciendo exponencialmente y la indus- 
tria del softwarecontinúa anunciando el crecimiento de ventas al doble. 
Parte de la respuesta, pienso, es que un importante número de estos 
proyectos «fallidos» están mal concebidos desde el primer momento. 
Los clientes pierden el interés rápidamente (puesto que lo que ellos 
pidieron realmente no era tan importante como ellos habían pensado), 
y los proyectos son cancelados. 
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3.2.2. Los jefes de equipo 


La gestión de un proyecto es una actividad intensamente 
humana, y por esta razón, los profesionales competen- 
tes del software a menudo no son buenosjefes de equi- 
po. Simplemente no tienen la mezcla adecuada de 
capacidades del personal. Y sin embargo, como dice 
Edgemon: «Desafortunadamente y con demasiada fre- 
cuencia, hay individuos que terminan en la gestión de 


proyectos y se convierten en gestores de proyecto acci- 
dentales» [EDG95]. 


le ¿En qué nos fijamos cuando 
seleccionamos a alguien para 
conducir un proyecto de software? 


En un excelente libro sobre gestión técnica, Jerry 
Weinberg [WEI86] sugiere el modelo de gestión MOI: 


Motivación.La habilidad para motivar (con un «tira y aflo- 
ja») al personal técnico para que produzca conforme a sus mejo- 
res capacidades. 


Organización. La habilidad para amoldar procesos exis- 
tentes (oinventar unos nuevos) que permita al concepto inicial 
transformarse en un producto final, 


Ideas oinnovación.La habilidad para motivar al personal 
para crear y sentirse creativos incluso cuando deban de traba- 
jar dentro de los límites establecidos para un producto o apli- 
cación de software particular. 


los un líder es aquel que sobe a 
levanto y vo. 


Weinberg sugiere que el éxito de los gestores de pro- 
yecto se basa en aplicar un estilo de gestión en la reso- 
lución de problemas. Es decir, un gestor de proyectos de 
software debería concentrarse en entender el problema 
que hay que resolver, gestionando el flujo de ideas y, al 
mismo tiempo, haciendo saber a todos los miembros del 
equipo (mediante palabras y, mucho más importante, 
con hechos) que la calidad es importante y que no debe 
verse comprometida. 

Otro punto de vista [EDG95] de las características 
que definen a un gestor de proyectos eficiente resalta 
cuatro apartados clave: 


Resolución del problema. Un gestor eficiente de un pro- 
yecto de software puede diagnosticar los aspectos técnicos y 
de organización más relevantes, estructurar una soluciónsiste- 
máticamente o motivar apropiadamente a otros profesionales 
para que desarrollenla solución, aplicarlas lecciones aprendi- 
das de anteriores proyectos a las nuevas situaciones, mante- 
nerse lo suficientementeflexible para cambiar la gestión si los 
intentos iniciales de resolver el problema no dan resultado. 


Dotes de gestión. Un buen gestor de proyectos debe tomar 
las riendas. Debe tener confianzapara asumir el control cuan- 
do sea necesarioy la garantía para permitir que los buenos téc- 
nicos sigan sus instintos. 


Incentivos por logros. Para optimizar la productividad de 
un equipo de proyecto, un gestor debe recompensar la inicia- 
tiva y los logros, y demostrar a través de sus propias acciones 
que no se penalizará si se corren riesgos controlados. 


Influencia y construcción de espíritu de equipo. Un ges- 
tor de proyecto eficiente debe ser capaz de «leer» a la gente; 
debe ser capaz de entender señales verbales y no verbales y 
reaccionar ante las necesidades de las personas que mandan 
esas señales. El gestor debe mantener el control en situaciones 
de gran estrés. 


Ronsuof) 


Un experto de software puede no tener temperamento o 
deseo de ser jefe de equipo. No fuerceal experto poro ser 
uno de ellos. 


3.2.3. El equipo de software 


Existen casi tantas estructuras de organización de perso- 
nal para el desarrollo de software como organizaciones 
que se dedican a ello. Para bien O para mal, el organi- 
grama no puede cambiarse fácilmente. Las consecuen- 
cias prácticas y políticas de un cambio de organización 
no están dentro del alcance de las responsabilidades del 
gestor de un proyecto de software. Sinembargo, la orga- 
nización del personal directamente involucrado en un 
nuevo proyecto de software está dentro del ámbito del 
gestor del proyecto. 

Las siguientes opciones pueden aplicarse a los recur- 
sos humanos de un proyecto que requiere n personas 
trabajando durante k años: 


1. n individuos son asignados a m diferentes tareas fun- 
cionales, tiene lugar relativamente poco trabajo con- 
junto; la coordinación es responsabilidad del gestor 
del software que puede que tenga otros seis proyec- 
tos de los que preocuparse. 


Ue 


rupo es Un equipo, y no todo equipo 


2. nindividuos son asignados a m diferentes tareas fun- 
cionales (m<n) de manera que se establecen «equi- 
p o s mformales; se puede nombrar un líder al efecto; 
la coordinación entre los equipos es responsabilidad 
de un gestor del software. 


3. nindividuos se organizan en f equipos; a cada equipo 
se le asignan una O más tareas funcionales; cada 
equipo tiene una estructura específica que se define 
para todos los equipos que trabajan en el proyecto; 
la coordinación es controlada por el equipo y por el 
gestor del proyecto de software. 


Aunque es posible encontrar argumentos en pro y en 
contra para cada uno de los enfoques anteriores, existe 
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una gran evidencia que indica que una organización de 
equipo formal (opción 3) es la más productiva. 

La «mejor» estructura de equipo depende del esti- 
lo de gestión de una organización, el número de per- 
sonas que compondrá el equipo, sus niveles de 
preparación y la dificultad general del problema. Man- 
tei [MANS81] sugiere tres organigramas de equipo 
genéricos: 

Descentralizado democrático (DD). Este equipo de 
ingeniería del software no tiene un jefe permanente. Más 
bien, «se nombran coordinadores de tareas a corto plazo y 
se sustituyen por otros para diferentes tareas». Las deci- 


siones sobre problemas y los enfoques se hacen por con- 
senso del grupo. La comunicación entre los miembros del 


equipo es horizontal. 
e ¿Cómo debería estar 
organizado un equipo 
de software? 


Descentralizadocontrolado (DC). Este equipo de inge- 
niería del software tiene un jefe definido que coordina tare- 
as específicas y jefes secundariosque tienen responsabilidades 
sobre subtareas. La resolución de problemas sigue siendo 
una actividad del grupo, pero la implementación de solu- 
ciones se reparte entre subgrupos por el jefe de equipo. La 
comunicación entre subgrupos e individuos es horizontal. 
También hay comunicación vertical a lo largo de lajerarquía 
de control. 


Centralizado controlado (CC). Eljefe del equipo se 
encarga de la resolución de problemas a alto nivel y la coor- 
dinación interna del equipo. La comunicación entre eljefe y 
los miembros del equipo es vertical. 


Mantei [MANS81] describe siete factores de un pro- 
yecto que deberían considerarse cuando se planifica el 
organigrama de equipos de ingeniería del software: 


» la dificultad del problema que hay que resolver 

» el tamaño del programa(s) resultante(s) en líneas de 
código o puntos de función (Capítulo 4) 

» el tiempo que el equipo estará junto (tiempo de vida 
del equipo) 


+ el grado en que el problema puede ser modulari- 
zado 


Qué factores 
deberíamos considerar 
cuando estructuramos 

un equipo de software? 


* la calidad requerida y fiabilidad del sistema que se 
va a construir 


» larigidez de la fecha de entrega 


+ el grado de sociabilidad (comunicación) requerido 
para el proyecto 


Debido a que una estructura centralizada realiza las 
tareas más rápidamente, es la más adecuada para mane- 
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jar problemas sencillos. Los equipos descentralizados 
generan más y mejores soluciones que los individua- 
les. Por tanto, estos equipos tienen más probabilidades 
de éxito en la resolución de problemas complejos. Pues- 
to que el equipo DC es centralizado para la resolución 
de problemas, tanto el organigrama de equipo DC como 
el de CC pueden aplicarse con éxito para problemas 
sencillos. La estructura DD es la mejor para problemas 
difíciles. 

Como el rendimiento de un equipo es inversamente 
proporcional a la cantidad de comunicación que se debe 
entablar, los proyectos muy grandes son mejor dirigi- 
dos por equipos con estructura CC o DC, donde se pue- 
den formar fácilmente subgrupos. 

El tiempo que los miembros del equipo vayan a 
«vivir juntos» afecta a la moral del equipo. Se ha des- 
cubierto que los organigramas de equipo tipo DD pro- 
ducen una moral más alta y más satisfacción por el 
trabajo y son, por tanto, buenos para equipos que per- 
manecerán juntos durante mucho tiempo. 

El organigrama de equipo DD se aplica mejor a pro- 
blemas con modularidad relativamente baja, debido a 
la gran cantidad de comunicación que se necesita. Los 
organigramas CC o DC funcionan bien cuando es posi- 
ble una modularidad alta (y la gente puede hacer cada 
uno lo suyo). 


loop 


Frecuentementees mejor tenerpocos equipos pequeños, 
bien centrados que un gran equipo solamente. 


Los equipos CC y DC producen menos defectos que 
los equipos DD, pero estos datos tienen mucho que ver 
con las actividades específicas de garantía de calidad 
que aplica el equipo. Los equipos descentralizados 
requieren generalmente más tiempo para completar un 
proyecto que un organigrama centralizado y al mismo 
tiempo son mejores cuando se precisa una gran canti- 
dad de comunicación. 

Constantine [CON93] sugiere cuatro «paradigmas 
de organización» para equipos de ingeniería del soft- 
ware: 


1. Unparadigma cerrado estructura a un equipo con 
una jerarquía tradicional de autoridad (similar al 
equipo CC). Estos equipos trabajan bien cuando pro- 
ducen software similar a otros anteriores, pero pro- 
bablemente sean menos innovadores cuando trabajen 
dentro de un paradigma cerrado. 


2. El paradigma aleatorio estructura al equipo libre- 
mente y depende de la iniciativa individual de los 
miembros del equipo. Cuando se requiere innova- 
ción O avances tecnológicos, los equipos de para- 
digma aleatorio son excelentes. Pero estos equipos 
pueden chocar cuando se requiere un «rendimiento 
ordenado». 
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3. El paradigma abierto intenta estructurar a un equipo 
de manera que consiga algunos de los controles aso- 
ciados con el paradigma cerrado, pero también 
mucha de la innovación que tiene lugar cuando se 
utiliza el paradigma aleatorio. El trabajo se desa- 
rrolla en colaboración, con mucha comunicación y 
toma de decisiones consensuadas y con el sello de 
los equipos de paradigma abierto. Los organigra- 
mas de equipo de paradigma abierto son adecuados 
para la resolución de problemas complejos, pero 
pueden no tener un rendimiento tan eficiente como 
otros equipos. 


equipo es difícil, pero no imposible. 


. El paradigma sincronizado se basa en la comparti- 
mentación natural de un problema y organiza los 
miembros del equipo para trabajar en partes del pro- 
blema con poca comunicación activa entre ellos. 


Constantine [CON93] propone una variación en el 
equipo descentralizado democrático defendiendo a los 
equipos con independencia creativa cuyo enfoque de 
trabajo podría ser mejor llamado «anarquía innova- 
dora». Aunque se haya apelado al enfoque de libre 
espíritu para el desarrollo del software, el objetivo 
principal de una organización de Ingeniería del Soft- 
ware debe ser «convertir el caos en un equipo de alto 
rendimiento» [HYM93]. Para conseguir un equipo de 
alto rendimiento. 


+ Los miembros del equipo deben confiar unos en 
Otros. 


+ La distribución de habilidadesdebe adecuarse al pro- 
blema. 


+ Para mantener la unión del equipo, los inconformis- 
tas tienen que ser excluidos del mismo 


Cualquiera que sea la organización del equipo, el 
objetivo para todos los gestores de proyecto es colabo- 
rar a crear un equipo que presente cohesión. En su libro, 
Peopfeware, DeMarco y Lister [DEM98] estudian este 
aspecto: 


Epapel del bibliotecario existe sin tener en cuento 
lo estructura del equipo. Poro más detalles véase 
el Capítulo 9, 


Tendemos a usar la palabra equipo demasiado libre- 
mente en el mundo de los negocios, denominando «equi- 
po» a cualquier grupo de gente asignado para trabajar junta. 
Pero muchos de estos grupos no parecen equipos. No tie- 
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nen una definición común de éxito o un espíritu de equi- 
po identificable. Lo que falta es un fenómeno que deno- 
minamos cuajar. 


Un equipo cuajado es un grupo de gente tejido tan fuer- 
temente que el todo es mayor que la suma de las partes... 


Una vez que el equipo empieza a cuajar, la probabilidad 
de éxito empieza a subir. El equipo puede convertirse en 
imparable, un monstruo de éxito ... No necesitan ser dirigi- 
dos de una manera tradicional y no necesitan que se les moti- 
ve. Están en su gran momento. 


DeMarco y Lister mantienen que los miembros de 
equipos cuajados son significativamente más pro- 
ductivos y están más motivados que la media. Com- 
parten una meta común, una cultura común y, en 
muchos casos, un «sentimiento elitista» que les hace 
únicos. 

Pero no todos los equipos cuajan. De hecho, muchos 
equipos sufren lo que Jackman llama «toxicidadde equi- 
po» [JAC98] define cinco factores que «fomentan un 
entorno de equipo tóxico potencial»: 


cual sea el problema, siempre 
dlemo del equipo. 


1. una atmósfera de trabajo frenética en la que los 
miembros del equipo gastan energía y se descentran 
de los objetivos del trabajo a desarrollar; 


. alta frustración causada por factores tecnológicos, 
del negocio, o personales que provocan fricción entre 
los miembros del equipo; 


3. «procedimientos coordinados pobremente o frag- 
mentados» o una definición pobre o impropiamente 
elegida del modelo de procesos que se convierte en 
un obstáculo a saltar; 


. definición confusa de los papeles a desempeñar pro- 
duciendo una falta de responsabilidad y la acusación 
correspondiente, y 


. «continua y repetida exposición al fallo» que con- 
duce a una pérdida de confianza y a una caída de la 
moral. 


Jackman sugiere varios antitóxicos que tratan los 
problemas comunes destacados anteriormente. 

Para evitar un entorno de trabajo frenético, el 
gestor de proyectos debería estar seguro de que el 
equipo tiene acceso a toda la información requerida 
para hacer el trabajo y que los objetivos y metas prin- 
cipales, una vez definidos, no deberían modificarse a 
menos que fuese absolutamente necesario. Además, 
las malas noticias no deberían guardarse en secreto, 
sino entregarse al equipo tan pronto como fuese posi- 
ble (mientras haya tiempo para reaccionar de un modo 
racional y controlado). 
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los equipos formados son lo ideal, pero no esfácil 
conseguirlos. Como mínimo, esté seguro de evitar 
un «entorno tóxico». 


Aunque la frustración tiene muchas causas, los desa- 
rrolladores de software a menudo la sienten cuando pier- 
den la autoridad para controlar la situación. Un equipo 
de software puede evitar la frustración si recibe tanta 
responsabilidad para la toma de decisiones como sea 
posible. Cuanto más control se le de al equipo para tomar 
decisiones técnicas y del proceso, menos frustración 
sentiran los miembros del equipo. 

Una elección inapropiada del proceso del software 
(p.ej., tareas innecesarias O pesadas, pobre elección de 
los productos del trabajo) puede ser evitada de dos for- 
mas: (1) estando seguros de que las características del 
software a construir se ajustan al rigor del proceso ele- 
gido, y (2) permitiendo al equipo seleccionar el proce- 
so (con el reconocimiento completo de que, una vez 
elegido, el equipo tiene la responsabilidad de entregar 
un producto de alta calidad). 

El gestor de proyectos de software, trabajando 
junto con el equipo, debería refinar claramente los roles 
y las responsabilidadesantes del comienzo del proyec- 
to. El equipo debería establecer su propios mecanismos 
para la responsabilidad (las revisiones técnicas forma- 
les? son una forma para realizar esto) y definir una serie 
de enfoques correctivos cuando un miembro del equi- 
po falla en el desarrollo. 
Todo equipo de software experimentapequeños fallos. 
La clave para eliminar una atmósfera de fallos será esta- 
blecer técnicas basadas en el equipo para retroalimentar 
y solucionar el problema. Además, cualquier fallo de un 
miembro del equipo debe ser considerado como un fallo 
del equipo. Esto lleva a un acercamiento del equipo a la 
acción correctiva, en lugar de culpar y desconfiar, que 
ocurre con rapidez en equipos tóxicos. 


¿Cómo debemos evitar 
E" «toxinas» que con frecuencia 
infectan un equipo de software? 


Además de las cinco toxinas descritas por Jackman, 
un equipo de software a menudo se enfrenta con los ras- 
gos humanos diferentes de sus miembros. Algunos 
miembros del equipo son extrovertidos, otros son intro- 
vertidos. Algunas personas recogen información intui- 
tivamente, separando amplios conceptos de hechos 
dispares. Otros procesan la información linealmente, 
reuniendo y organizando detalles minuciosos de los 
datos proporcionados. Algunos miembros del equipo 
toman las decisiones apropiadas solamente cuando se 


3 Las revisiones técnicas formales se tratan con detalle en el Capi- 
tulo 8. 
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presenta un argumento lógico, de un modo ordenado. 
Otros son intuitivos, pudiendo tomar una decisión basán- 
dose en sus «sensaciones».Algunos desarrolladorespre- 
fieren una planificación detallada compuesta por tareas 
organizadas que les permita lograr el cierre para algún 
elemento de un proyecto. Otros prefieren un entorno 
más espontáneo donde aspectos abiertos son correctos. 
Algunos trabajan duro para tener las cosas hechas mucho 
antes de la fecha de un hito, de ese modo eliminan la 
presión cuando se aproximan a las fechas, mientras que 
otros están apurados por las prisas para hacer la entre- 
ga en el Último minuto. Un estudio detallado de la psi- 
cología de estos rasgos y de las formas en las que un 
jefe de equipo cualificado puede ayudar a la gente con 
rasgos opuestos para trabajarjuntos está fuera del ámbi- 
to de éste libro*. Sin embargo, es importante destacar 
que el reconocimiento de las diferencias humanas es el 
primer paso hacia la creación de equipos que cuajan. 


3.2.4, Aspectos sobre la coordinación 
y la comunicación 


Hay muchos motivos por los que los proyectos de soft- 
ware pueden tener problemas. La escala (tamaño) de 
muchos esfuerzos de desarrollo es grande, conduciendo 
a complejidades, confusión y dificultades significativas 
para coordinar a los miembros del equipo. La incerti- 
dumbre es corriente, dando como resultado un continuo 
flujo de cambios que impactan al equipo del proyecto. 
La interoperatividad se ha convertido en una caracterís- 
tica clave de muchos sistemas. El software nuevo debe 
comunicarse con el anterior y ajustarse a restricciones 
predefinidas impuestas por el sistema o el producto. 


Cita: 
3 hacer: no hay alternativa. 
Wars) 


Estas características del software moderno —esca- 
la, incertidumbre e interoperatividad —son aspectos de 
la vida. Para enfrentarse a ellos eficazmente, un equi- 
po de ingeniería del software debe establecer métodos 
efectivos para coordinar a la gente que realiza el tra- 
bajo. Para lograr esto se deben establecer mecanismos 
de comunicación formales e informales entre los miem- 
bros del equipo y entre múltiples equipos. La comuni- 
cación formal se lleva a cabo «por escrito, con reuniones 
organizadas y otros canales de comunicación relativa- 
mente no interactivos e impersonales» [KRA95]. La 
comunicación informal es más personal. Los miembros 
de un equipo de software comparten ideas de por sí, 
piden ayuda a medida que surgen los problemas e inter- 
actúan los unos con los otros diariamente. 


4 Se puede encontrar una excelente introducción a estos temas rela- 
cionados con los equipos de proyectos de software en [FER98] 
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discusión entre personas A 


. Mi hitos ecto 
EN de Seguimiento 
de errores 
€revisiones de estado 
correo electrónico 


e inspecciones de código 


revisiones de diseño 4 
revisiones de requisitose 
disposición O 

reuniones de grupo 


a 


O boletines del proyecto 


mcódigo fuente 
1 contenido del diccionario de datos 


valor de la técnica de coordinación 


1 herramientas de control del proyecto 


2 3 4 5 
empleo de la técnica de coordinación 


m Enfoque impersonal, formal 
e Procedimiento interpersonal, formal 
o Procedimiento interpersonal, informal 


O Comunicación electrónica 
A Red interpersonal 


FIGURA 3.1. Valor y empleo de técnicas de coordinación 
y comunicación. 


Kraul y Streeter [KRA95] examinan una colección 
de técnicas de coordinación de proyectos que se cate- 
gorizan de la siguiente manera: 


Formal, enfoque impersonal. Incluyen documentos de 
ingeniería del software y entregas (incluyendoel código fuen- 
te), memorandos técnicos, hitos del proyecto, planificacio- 
nes del programa y herramientas de control del proyecto 
(Capítulo 7), peticiones de cambios y documentación relati- 
va (Capítulo 9), informes de seguimiento de errores e infor- 
mación almacenada (Capítulo 31). 


Formal, procedimientosinterpersonales. Se centra en 
las actividades de garantía de calidad (Capítulo 8) aplicada 


a productos de ingeniería del software. Estos incluyen reu- 
niones de revisión de estado e inspecciones de diseño y de 
¿Cómo coordinar 


código. 
E las acciones de los miembros 
del equipo? 


Informal, procedimientos interpersonales. Incluyen reu- 
niones de grupo para la divulgación de información y resolu- 
ción de problemas así como «definición de requisitos y del 
personal de desarrollo». 


Comunicación electrónica. Comprende correo electróni- 
co, boletines de noticias electrónicos y, por extensión, sistemas 
de videoconferencia. 


Red interpersonal. Discusiones informales con los miem- 
bros del equipo y con personas que no están en el proyecto pero 
que pueden tener experiencia o una profunda visión que pue- 
de ayudar a los miembros del equipo. 


Para valorar la eficacia de estas técnicas para la coor- 
dinación de proyectos, Kraul y Streeter estudiaron 65 
proyectos de software con cientos de personas implica- 
das. La Figura 3.1 (adaptada de [KRA95]) expresa el 
valor y empleo de las técnicas de coordinación apunta- 
das anteriormente. En la figura, el valor percibido (cla- 
sificadoen una escala de siete puntos) de varias técnicas 
de comunicación y coordinación es contrastado con su 
frecuenciade empleo en un proyecto. Las técnicas situa- 
das por encima de la línea de regresión fueron «juzga- 
das como relativamente valiosas, dado la cantidad de 
veces que se emplearon» [KRA9S]. Las técnicas situa- 
das por debajo de la línea se consideraron de menor valor. 
Es interesante resaltar que las redes interpersonales fue- 
ron catalogadas como las técnicas de mayor valor de 
coordinación y de comunicación. Es también importan- 
te hacer notar que los primeros mecanismos de garantía 
de calidad del software (requisitos y revisiones de dise- 
ño) parecieron tener más valor que evaluaciones poste- 
riores de código fuente (inspecciones de código). 


El gestor de un proyecto de software se enfrenta a un dile- 
ma al inicio de un proyecto de ingeniería del software. 
Se requieren estimaciones cuantitativas y un plan orga- 
nizado, pero no se dispone de información sólida. Un 
análisis detallado de los requisitos del software pro- 
porcionaría la información necesaria para las estima- 
ciones, pero el análisis a menudo lleva semanas O meses. 
Aún peor, los requisitos pueden ser fluidos, cambiando 
regularmente a medida que progresa el proyecto. Y, aún 
así, se necesita un plan «¡ya!». 


Por tanto, debemos examinar el producto y el pro- 
blema a resolver justo al inicio del proyecto. Por lo 
menos se debe establecer el ámbito del producto y 
delimitarlo. 
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3.3.1. Ámbito del software 

La primera actividad de gestión de un proyecto de soft- 
ware es determinar el ámbito del software. El ámbito se 
define respondiendo a las siguientes 'cuestiones: 


Cons) 


Sino puede delimitar una característica de/software 
que intento construir, considerela característica como 
un riesgo principal de/proyecto. 


Contexto. ¿Cómo encaja el software a construir 
en un sistema, producto o contexto de negocios 
mayor y qué limitaciones se imponen como resulta- 
do del contexto? 


www.elsolucionario.net 


Objetivosde información. ¿Qué objetos de datos 
visibles al cliente (Capítulo 11)se obtienen del softwa- 
re? ¿Qué objetos de datos son requeridos de entrada? 

Función y rendimiento. ¿Qué función realiza el 
software para transformar la información de entra- 
da en una salida? ¿Hay características de rendimiento 
especiales que abordar? 


El ámbito de un proyecto de software debe ser uní- 
voco y entendible a niveles de gestión y técnico. Los 
enunciados del ámbito del software deben estar deli- 
mitados. 

Es decir, los datos cuantitativos (por ejemplo: núme- 
ro de usuarios simultáneos, tamaño de la lista de correo, 
máximo tiempo de respuesta permitido) se establecen 
explícitamente;se anotan las limitaciones (por ejemplo: 
el coste del producto limita el tamaño de la memoria) y 
se describen los factores de reducción de riesgos (por 
ejemplo: los algoritmos deseados se entienden muy bien 
si están disponibles en C++). 


3.3.2, Descomposición del problema 


La descomposición del problema, denominadoa veces 
particionado o elaboración del problema, es una activi- 
dad que se asienta en el núcleo del análisis de requisitos 
del software (Capítulo 11). Durante la actividad de expo- 
sición del ámbito no se intenta descomponer el proble- 
ma totalmente. Más bien, la descomposición se aplicaen 
dos áreas principales: (1) la funcionalidadque debe entre- 
garse y (2) el proceso que se empleará para entregarlo. 


» 
Ss 


CLAVE 


Para desarrollarun plan de proyecto razonable, tiene 
que descomponer funcionalmente el problema a resolver 


Los seres humanos tienden a aplicar la estrategia de 
divide y vencerás cuando se enfrentan a problemas com- 
plejos. Dicho de manera sencilla, un problema complejo 
se parte en problemas más pequeños que resultan más 
manejables. Ésta es la estrategia que se aplica al inicio 
de la planificación del proyecto. 
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Las funciones del software, descritas en la exposi- 
ción del ámbito, se evalúan y refinan para proporcionar 
más detalle antes del comienzo de la estimación (Capí- 
tulo 5). Puesto que ambos, el coste y las estimaciones 
de la planificación temporal, están orientados funcio- 
nalmente, un pequeño grado de descomposición suele 
ser útil. 

Por ejemplo, considere un proyecto que construirá 
un nuevo procesador de textos. Entre las características 
peculiares del producto están: la introducción de infor- 
mación a través de la voz así como del teclado; carac- 
terísticas extremadamente sofisticadas de «edición 
automática de copia»; capacidad de diseño de página; 
indexación automática y tabla de contenido, y otras. El 
gestor del proyecto debe establecer primero la exposi- 
ción del ámbito que delimita estas características (así 
como otras funciones más normales, como edición, 
administración de archivos, generación de documen- 
tos). Por ejemplo, ¿requerirá la introducción de infor- 
mación mediante voz «entrenamiento» por parte del 
usuario? ¿Qué capacidades específicas proporcionará 
la característica de editar copias? ¿Exactamente cómo 
será de sofisticado la capacidad de diseño de página? 


Referencia cruzada 


Enel Capítulo 12 se presento una fécnico útil paro 
descomponer el problema, lamoda «análisis gramatical». 


A medida que evoluciona la exposición del ámbito, 
un primer nivel de partición ocurre de forma natural. El 
equipo del proyecto sabe que el departamento de mar- 
keting ha hablado con clientes potenciales y ha averi- 
guado que las siguientes funciones deberían ser parte 
de la edición automática de copia: (1) comprobación 
ortográfica; (2) comprobación gramatical; (3)compro- 
bación de referencias para documentos grandes (p. ej.: 
¿se puede encontrar una referencia a una entrada biblio- 
gráficaen la lista de entradas de la bibliografía?), y (4) 
validación de referencias de sección y capítulo para 
documentos grandes. Cada una de estas características 
representa una subfunción para implernentar en soft- 
ware. Cada una puede ser aún más refinada si la des- 
composición hace más fácil la planificación. 


Las fases genéricas que caracterizan el proceso de soft- 
ware definición, desarrollo y soporte — son aplicables 
atodo software. El problema es seleccionarel modelo de 
proceso apropiadopara la ingeniería del software que debe 
aplicar el equipo del proyecto. En el Capítulo2 se estudió 
una gran gama de paradigmas de ingeniería del software: 


+ el modelo secuencial lineal 
+ el modelo de prototipo 
*« el modelo DRA 
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+ el modelo incremental 
+ el modelo en espiral 
= el modelo en espiral WINWIN 


» el modelo de desarrollo basado (ensamblaje) en com- 
ponentes 


= el modelo de desarrollo concurrente 
+ el modelo de métodos formales 
= el modelo de técnicas de cuarta generación 
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INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRACTICO 


Cons) 


Uno vez eleyido el modelo de proceso, ocompóñelo con 
el mínimo conjunto de tareas de trabajo y productos que 
desembocaronen un producto de alta calidad - e vite la 
copocidad de destuccióndelprocese. 


El gestor del proyecto debe decidir qué modelo de 
proceso es el más adecuado para (1) los clientes que han 
solicitado el producto y la gente que realizará el traba- 
jo; (2)las características del producto en sí, y (3 )el entor- 
no del proyecto en el que trabaja el equipo de software. 
Cuando se selecciona un modelo de proceso, el equipo 
define entonces un plan de proyecto preliminar basado 
en un conjunto de actividades estructurales. Una vez 
establecido el plan preliminar, empieza la descomposi- 
ción del proceso. Es decir, se debe crear un plan com- 
pleto reflejando las tareas requeridas a las personas para 
cubrir las actividades estructurales. Exploramos estas 
actividades brevemente en las secciones que siguen y 
presentamos una visión más detallada en el Capítulo 7. 


3.4,1. Maduración del producto y del proceso 


La planificación de un proyecto empieza con la madu- 
ración del producto y del proceso. Todas las funciones 
que se deben tratar dentro de un proceso de ingeniería 
por el equipo de software deben pasar por el conjunto 
de actividades estructurales que se han definido para 
una organización de software. Asuma que la organiza- 
ción ha adoptado el siguiente conjunto de actividades 
estructurales (Capítulo 2): 


ACTIVIDADES ESTRUCTURALES 
DE PROCESO COMUNES 


Tareas de Ingeniería del Software 


Funciones del producto 


+. Comunicación con el cliente — tareas requeridas para 
establecer la obtención de requisitos eficiente entre 
el desarrollador y el cliente. 

. Planificación — tareas requeridas para definir los 
recursos, la planificación temporal del proyecto y 
cualquier información relativa a él. 


Rionsuof) 


Recuerde.....las actividades estructurales se aplican 
en todos los proyectos- no hoy excepciones. 


+ Análisis del riesgo — tareas requeridas para valorar 
los riesgos técnicos y de gestión. 

+ Ingeniería— tareas requeridas para construir una o 
más representaciones de la aplicación. 

+ Construccióny entrega — tareas requeridas para cons- 
truir, probar, instalar y proporcionar asistencia al usua- 
rio (por ejemplo: documentación y formación). 

« Evaluación del cliente — tareas requeridas para obte- 
ner información de la opinión del cliente basadas en 
la evaluación de las representaciones de software 
creadas durante la fase de ingeniería e implementa- 
das durante la fase de instalación. 

Los miembros del equipo que trabajanen cada función 
aplicarán todas las actividades estructurales. En esencia, 
se crea una matriz similar a la que se muestra en la Figu- 
ra 3.2. Cada función principal del problema (la figura con- 
tiene las funciones para el software procesador de textos 
comentado anteriormente) se lista en la columna de la 
izquierda. Las actividades estructurales se listan en la fila 


Introducción de texto 


Edición y formateo 


Edición automática de copia 


Capacidad de diseño de página 


Indexación automática y TOC 


Administración de archivos 


Producción de documentos 


FIGURA 3.2.Maduración del problema y del proceso. 
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de arriba. Las tareas de trabajo de ingeniería del software 
(para cada actividad estructural) se introducirían en la fila 
siguiente”, El trabajo del gestor del proyecto (y de otros 
miembros del equipo) es estimar los requisitos de recur- 
sos para cada celda de la matriz, poner fechas de inicio y 
finalización para las tareas asociadas con cada celda y los 
productos a fabricar como consecuencia de cada celda. 
Estas actividades se consideran en los Capítulos 3 y 7. 


CLAVE 


La descomposición del producto y del proceso se produce 
simultóneamente con la evolución del plan de proyecto. 


3.4,2, Descomposición del proceso 

Un equipo de software debería tener un grado significa- 
tivo de flexibilidad en la elección del paradigma de inge- 
niería del software que resulte mejor para el proyecto y 
de las tareas de ingeniería del softwareque conforman el 
modelo de proceso una vez elegido. Un proyecto relati- 
vamente pequeño similara otros que se hayan hecho ante- 
riormente se debería realizar con el enfoque secuencial 
lineal. Si hay límites de tiempo muy severos y el proble- 
ma se puede compartimentarmucho, el modelo apropia- 
do es el DRA (en inglés RAD). Si la fecha límite está tan 
próxima que no va a ser posible entregar toda la funcio- 
nalidad, una estrategia incremental puede ser lo mejor. 
Similarmente,proyectos con otras características (p. ej.: 
requisitos inciertos, nuevas tecnologías, clientes difíci- 
les, potencialidad de reutilización) llevarán a la selección 
de otros modelos de proceso”. 


Eonsuof) 


Aplique siempre la ECP (Estructura Común de Proceso), 
sin tener en cuenta el tamaño, criticidad o tipo del 
proyecto. Las tareas pueden variar pero la ECP no. 


Una vez que se ha elegido el modelo de proceso, la 
estructuracomún de proceso (ECP) se adapta a él. En todos 
los casos, el ECP estudiado anteriormente en este capítu- 
lo -comunicación con el cliente, planificación, análisis 
de riesgo, ingeniería, construcción, entrega y evaluación 
del cliente — puede adaptarse al paradigma. Funcionará 
para modelos lineales, para modelos iterativos e incre- 
mentales, para modelos de evolución e incluso para mode- 
los concurrenteso de ensamblaje de componentes. El ECP 
es invariable y sirve como base para todo el trabajo de 
software realizado por una organización. 

Pero las tareas de trabajo reales sí varían. La descom- 
posición del proceso comienza cuando el gestor del pro- 
yecto pregunta: «¿Cómo vamos a realizar esta actividad 


5 Se hace notar que las tareas se deben adaptar a las necesidades 
específicas de un proyecto. Las actividades estructurales siempre per- 
manecen igual, pero las tareas se seleccionarán basándose en unos 
criterios de adaptación. Este tema es discutido más adelante en el 
Capitulo 7 y en la página Web SEPA 57e. 
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ECP?», Por ejemplo, un pequeño proyecto, relativamen- 
te simple, requiere las siguientes tareas para la actividad 
de comunicación con el cliente: 
1. Desarrollar una lista de aspectos que se han de cla- 
rificar. 
2. Reunirse con el cliente para resolver los aspectos 
que se han de clarificar. 
3. Desarrollar conjuntamente una exposición del 
ámbito del proyecto. 
4. Revisar el alcance del proyecto con todos los impli- 
cados. 
5, Modificar el alcance del proyecto cuando se requiera. 


Estos acontecimientospueden ocurriren un periodo de 
menos de 48 horas. Representan una descomposición del 
problema apropiado para proyectos pequeños relativa- 
mente sencillos. 

Ahora, consideremos un proyecto más complejo que 
tenga un ámbito más amplio y un mayor impacto comer- 
cial. Un proyecto como ése podría requerir las siguientes 
tareas para la actividad de comunicación con el cliente: 


1. Revisar la petición del cliente. 

2. Planificar y programar una reunión formal con el 
cliente. 

3. Realizar una investigación para definir solucionespro- 
puestas y enfoques existentes. 

4. Preparar un «documentode trabajo» y una agenda para 
la reunión formal. 

5. Realizar la reunión. 

6. Desarrollar conjuntamente mini-especificaciones que 
reflejen la información, función y características de 
comportamiento del software. 


Modelo de proceso adaptable. 


7. Revisartodas las mini-especificaciones para compro- 
bar su corrección, su consistencia, la ausenciade ambi- 
gitedades. 

8. Ensamblar las mini-especificacionesen un documento 
de alcance del proyecto. 

9. Revisar ese documento general con todo lo que pueda 
afectar. 

10.Modificar el documento de alcance del proyecto 
cuando se requiera. 


Ambos proyectos realizan la actividad estructural que 
denominamos comunicacióncon el cliente, pero el equipo 
del primer proyecto lleva a cabo la mitad de tareas de 
ingeniería del software que el segundo. 


$ Recuerde que las características del proyecto tienen también una 
fuerte influencia en la estructura del equipo que va a realizar el tra- 
bajo. Vea la Sección 3.2.3. 
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INGENIERÍA DEL SOFTWAR 


AA PARE 


Para gestionar un proyecto de software con éxito, 
debemos comprender qué puede ir mal (para evitar 
esos problemas) y cómo hacerlo bien. En un excelente 
documento sobre proyectos de software, John Reel 
[REE99] define diez señales que indican que un pro- 
yecto de sistemas de información está en peligro: 


señales que indican el fallo de 
sistemas de información se 
desarrollo de un diseño 

línea de código. 


1.La gente del software no comprende las necesi- 
dades de los clientes. 


2. El ámbito del producto está definido pobremente. 
3.Los cambios están mal realizados. 
4. La tecnología elegida cambia. 


5. Las necesidades del negocio cambian [oestán mal 
definidas]. 


6.Las fechas de entrega no son realistas. 
7.Los usuarios se resisten. 


8. Se pierden los patrocinadores [o nunca se obtu- 
vieron adecuadamente]. 


9. El equipo del proyecto carece del personal con las 
habilidades apropiadas. 


10.Los gestores [y los desarrolladores] evitan buenas 
prácticas y sabias lecciones. 


Los profesionales veteranos de la industria hacen 
referencia frecuentemente a la regla 90-90 cuando 
estudian proyectos de software particularmente difí- 
ciles: el primer 90 por 100 de un sistema absorbe el 
90 por 100del tiempo y del esfuerzo asignado. El últi- 
mo 10por 100 se lleva el otro 90 por 100 del esfuer- 
zo y del tiempo asignado [ZAH94]. Los factores que 
conducen a la regla 90-90 están contenidos en las diez 
señales destacadas en la lista anterior. 

¡Suficiente negatividad! ¿Cómo actúa un gestor para 
evitar los problemas señalados anteriormente? Reel 
[REE99] sugiere una aproximación de sentido común 
a los proyectos de software dividida en cinco partes: 


Empezar con el pie derecho. Esto se realiza tra- 
bajando duro (muy duro) para comprender el pro- 
blema a solucionar y estableciendo entonces 
objetivos y expectativasrealistas para cualquieraque 
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vaya a estar involucrado en el proyecto. Se refuer- 
za construyendo el equipo adecuado (Sección 3.2.3) 
y dando al equipo la autonomía, autoridad y tecno- 
logía necesaria para realizar el trabajo. 


Mantenerse. Muchos proyectos no realizan un 
buen comienzo y entonces se desintegran lentamente. 
Para mantenerse, el gestor del proyecto debe pro- 
porcionar incentivos para conseguir una rotación del 
personal mínima, el equipo debería destacar la cali- 
dad en todas las tareas que desarrolle y los gestores 
veteranos deberían hacer todo lo posible por per- 
manecer fuera de la forma de trabajo del equipo”. 


Seguimiento del Progreso. Para un proyecto de 
software, el progreso se sigue mientras se realizan los 
productos del trabajo (por ejemplo, especificaciones, 
código fuente, conjuntos de casos de prueba) y se 
aprueban (utilizando revisiones técnicas formales) 
como parte de una actividad de garantía de calidad. 
Además, el proceso del software y las medidas del 
proyecto (capítulo4) pueden serreunidas y utilizadas 
para evaluar el progreso frente a promedios desarro- 
llados por la organización de desarrollo de software. 


Tomar Decisiones Inteligentes. En esencia, las 
decisiones del gestor del proyecto y del equipo de 
software deberían «seguir siendo sencillas». Siem- 
pre que sea posible, utilice software del mismo 
comercial o componentes de software existentes; 
evite personalizar interfaces cuando estén dispo- 
nibles aproximaciones estándar; identifique y eli- 
mine entonces riesgos obvios; asigne más tiempo 
del que pensaba necesitar para tareas arriesgadas 
o complejas (necesitará cada minuto). 


Referencia 


Se puede encontrar un gran conjunto de recursos 
que pueden ayudar tanto a gestores de proyecto 
experimentodos como a principiantes en: 
Wwww.pmi.org, Wwww.4pm.com y 
www.projectmanagement.com 


Realizar unAnálisis «Postmortem» (despuésde fina- 
lizar el proyecto]. Establecer un mecanismo consis- 
tente para extraer sabias lecciones de cada proyecto. 
Evaluar la planificación real y la prevista, reunir y ana- 
lizar métricas del proyecto de software y realimentar 
con datos de los miembros del equipo y de los clien- 
tes, y guardar los datos obtenidos en formato escrito. 


7 Esta frase implica la reducción al mínimo de la burocracia, y la eli- 
minación tanto de reuniones extrañas como de la adherencia dog- 
mática a las reglas del proceso y del proyecto. El equipo debena estar 
capacitado para realizar esto. 
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CAPITULO 3 CUNCEPIUS SOBRE GESTIÓN DE PROYECTOS 


En un excelente documento sobre proyectos y proce- 
so del software, Barry Boehm [BOE96] afirma: «... se 
necesita un principio de organización que haga una 
simplificación con el fin de proporcionar planes [de 
proyectos] sencillos para proyectos pequeños». Boehm 
sugiere un enfoque que trate los objetivos, hitos y pla- 
nificación, responsabilidades, enfoque técnico y de 
gestión, y los recursos requeridos del proyecto. Bohem 
lo llama el principio «WWWWWHH», después de 
una serie de preguntas (7 cuestiones) que conducen a 
la definición de las características clave del proyecto 
y el plan del proyecto resultante: 


¿Por qué se desarrolla el sistema? La respuesta a 
esta pregunta permite a todas las partes evaluar la vali- 
dez de las razones del negocio para el trabajo del soft- 
ware. Dicho de otra forma, ¿justifica el propósito del 
negocio el gasto en personal, tiempo, y dinero? 


¿Qué se realizaráy cuándo? La respuesta a estas 
preguntas ayuda al equipo a establecer la planifi- 
cación del proyecto identificando las tareas clave 
del proyecto y los hitos requeridos por el cliente. 


$ ¿Qué preguntas necesitan 
ser respondidas para 
desarrollar un Plan de Proyecto? 


¿Quién es el responsable de unafunción? Antes 
en este capítulo, señalamos que el papel y la res- 


ponsabilidad de cada miembro del equipo de soft- 
ware debe estar definida. La respuesta a la pre- 
gunta ayuda a cumplir esto. 


¿Dónde están situados organizacionalmente ? 
No todos los roles y responsabilidades residen en 
el equipo de software. El cliente, los usuarios, y 
otros directivos también tienen responsabilidades. 


ES : 
3 
Plan de Proyecto de Software 


¿Cómo estará realizado el trabajo desde el pun- 
to de vista técnico y de gestión? Una vez estable- 
cido el ámbito del producto, se debe definir una 
estrategia técnica y de gestión para el proyecto. 


¿Qué cantidad de cada recurso se necesita? La 
respuesta a esta pregunta se deriva de las estima- 
ciones realizadas (Capítulo 5) basadas en res- 
puestas a las preguntas anteriores. 


El principio WWHH de Boehm es aplicable sin tener 
en cuenta el tamaño o la complejidad del proyecto de 
software. Las preguntas señaladas proporcionan un 
perfil de planificación al gestor del proyecto y al equi- 
po de software. 


El Concilio* Airlie ha desarrollado una lista de 
«prácticas críticas de software para la gestión basada 
en el rendimiento». Estas prácticas son «utilizadas de 
un modo consistente por, y consideradas críticas por, 
organizaciones y proyectos de software de mucho éxi- 
to cuyo rendimiento “final” es más consistente que 
los promedios de la industria» [AIR99]. En un esfuer- 
ZO por permitir a una organización de software deter- 
minar si un proyecto específico ha implementado 
prácticas críticas, el Concilio Airlie ha desarrollado 
un conjunto de preguntas de «Visión Rápida» [AIR 99] 
para un proyecto”: 


Gestión formal del riesgo. ¿Cuáles son los diez 
riesgos principales para este proyecto? Para cada 


8 El Concilio Airlie es un equipo de expertos en ingeniería del software 
promocionado por el Departamento de Defensa U.S.ayudando en el 
desarrollo de directrices para prácticas importantes en la gestión de 
proyectos de software y en la ingeniería del Software. 


uno de los riesgos ¿cuál es la oportunidad de que 
el riesgo se convierta en un problema y cuál es el 
impacto si lo hace? 


Coste empírico y estimación de la planificación. 
¿Cuál es el tamaño actual estimado de la aplicación 
de software (sin incluir el software del sistema) que 
será entregada en la operación? ¿Cómo se obtuvo? 


a 


Visión rápida del Proyecto Airlie 


? Solo se destacan aquí aquellas practicas críticas relacionadas con 
la «integridad del proyecto)).Otras practicas mejores se trataran en 
capítulos posteriores. 
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Gestión de proyectos basada en métricas. ¿Dis- 
pone de un programa de métricas para dar una prime- 
ra indicación de los problemas del desarrollo? Si es así, 
¿cuál es la volatilidad de los requisitos actualmente? 


Seguimiento del valor ganado. ¿Informa men- 
sualmente de las métricas del valor ganado...? Si 
es así, ¿están calculadas estas métricas desde una 
red de actividades de tareas para el esfuerzo total 
a la próxima entrega? 


Seguimientode defectos frente a objetivos de cali- 
dad. ¿Realiza el seguimientoe informa periódicamente 
del número de defectosencontradosen cada prueba de 
inspección [revisión técnica formal] y ejecución des- 


de el principio del programa y del número de defectos 
que se corrigen y se producen en la actualidad? 


Gestión del programa del personal. ¿Cuál es 
la media de rotación de la plantilla en los tres Últi- 
mos meses por cada uno de los distribuidores/desa- 
rrolladores involucrados en el desarrollo del 
software para este sistema? 


Si un equipo de proyectos de software no puede 
responder a estas preguntas, o las responde inade- 
cuadamente, se debe realizar una revisión completa 
de las prácticas del proyecto. Cada una de las prácti- 
cas críticas señaladas anteriormente se tratan con deta- 
lle a lo largo de la Parte II de este libro. 


La gestión de proyectos de software es una actividad 
protectora dentro de la ingeniería del software. Empie- 
za antes de iniciar cualquier actividad técnica y con- 
tinúa a lo largo de la definición, del desarrollo y del 
mantenimiento del software. 

Hay cuatro « P”s » que tienen una influencia sustan- 
cial en la gestión de proyectos de software — personal, 
producto, proceso y proyecto —. El personal debe orga- 
nizarse en equipos eficaces, motivados para hacer un 
software de alta calidad y coordinados para alcanzar una 
comunicación efectiva. Los requisitos del producto 
deben comunicarse desde el cliente al desarrollador, 
dividirse (descomponerse) en las partes que lo consti- 
tuyen y distribuirse para que trabaje el equipo de soft- 
ware. El proceso debe adaptarse al personal y al 
problema. Se selecciona una estructura común de pro- 
ceso, se aplica un paradigma apropiado de ingeniería 
del software y se elige un conjunto de tareas para com- 


pletar el trabajo. Finalmente, el proyecto debe organi- 
zarse de una manera que permita al equipo de software 
tener éxito. 

El elemento fundamental en todos los proyectos de 
software es el personal. Los ingenieros del software 
pueden organizarse en diferentes organigramas de equi- 
po que van desde las jerarquías de control tradiciona- 
les a los equipos de «paradigma abierto». Se pueden 
aplicar varias técnicas de coordinación y comunica- 
ción para apoyar el trabajo del equipo. En general, las 
revisiones formales y las comunicaciones informales 
persona a persona son las más valiosas para los pro- 
fesionales. 

La actividad de gestión del proyecto comprende 
medición y métricas, estimación, análisis de riesgos, 
planificación del programa, seguimiento y control. 
Cada uno de estos aspectos se trata en los siguientes 
capítulos. 


[ATR99] Airlie Council, «Performanced Based Management: 
The Program Manager”s Guide Based on the 16-Point 
Plan and Related Metrics», Draft Report, 8 de Marzo, 
1999. 

[BAK72] Baker, F.T., «Chief Programmer Team Manage- 
ment of Production Programming», IBM Systems Jour- 
nal, vol. 11,n.£ 1, 1972, pp. 56-73. 


[BOE96] Boehm, B., «Anchoring the Software Process», 
IEEE Software, vol. 13,n.2 4, Julio de 1996, pp. 73-82. 


[CON93] Constantine, L., «Work Organization: Paradigms 
for Project Management and Organization», CACM, vol. 
36,n.* 10,Octubre de 1993, pp. 34-43. 

[COU80] Cougar, J., y R. Zawacky, Managing and Moti- 
vating Computer Personnel, Wiley, 1980. 


[CUR88] Curtis, B., et al, «A Field Study of the Software 
Design Process for Large Systems», IEEE Trans. Soft- 
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ware Engineering, vol. 31, n.* 11, Noviembre de 1988, 
pp. 1268-1287. 


[CUR94] Curtis, B., et al., People Management Capabi- 
lity Maturity Model, Software Engineering Institute, 
Pittsburgh, PA, 1994. 


[DEM98] DeMarco, T., y T. Lister, Peopleware, 2.* edi- 
ción, Dorset House, 1998. 


[EDG95] Edgemon, J., «Right Stuff How to Recognize 
It When Selecting a Project Manager», Application 
Development Trends, vol. 2, n.? 5, Mayo de 1995, pp. 
37-42. 


[FER98] Ferdinandi, P. L., «Facilating Communication», 
IEEE Software, Septiembre de 1998, pp. 92-96. 


[JAC98] Jackman, M., «Homeopathic Remedies for Team 
Toxicity», IEEE Software, Julio de 1998, pp. 43-45. 
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[KRA95] Kraul, R., y L. Streeter, «Coordination in Software 
Development», CACM, vol. 38, n.* 3, Marzo de 1995, pp. 
69-81. 


[MAN81] Mantei, M., «The Effect of Programming Team 
Structureson Programming Tasks», CACM, vol. 24, n.2 3, 
Marzo de 1981, pp. 106-113. 


[PAG85] Page-Jones, M., Practical Project Management, 
Dorset House, 1985,p. VII. 


CAPÍTULO 3 CONCEPTOS SOBRE GESTIÓN DE PROYECTOS 


[REE99] Reel, J.S., «Critical Suceess Factors in Software 
Projects», IEEE Software, Mayo de 1999,pp. 18-23. 


[WEI86] Weinberg, G., On Becoming a Technical Leader, 
Dorset House, 1986. 

[WIT94] Whitaker, K., Managing Software Maniacs, Wiley, 
1994. 


[ZAH94] Zahniser, R., «Timeboxing for Top Team Perfor- 
mance», Software Development, Marzo de 1994,pp. 35-38. 


3.1. Basándose en la información contenida en este capítu- 
lo y en su propia experiencia, desarrolle «diez mandamien- 
tos» para potenciar a los ingenieros del software. Es decir, 
haga una lista con las diez líneas maestras que lleven al per- 
sonal que construye software a su máximo potencial. 


3.2. El Modelo de Madurez de Capacidad de Gestión de Per- 
sonal (MMCGP) del Instituto de Ingeniería del Software hace 
un estudio organizado de las «áreas clave prácticas (ACP)» 
que cultivan los buenos profesionales del software. Su profe- 
sor le asignará una ACP para analizar y resumir. 


3.3. Describa tres situaciones de la vida real en las que el 
cliente y el usuario final son el mismo. Describa tres situa- 
ciones en que son diferentes. 


34. Las decisiones tomadas por una gestión experimentada 
pueden tener un impacto significativoen la eficaciade un equi- 
po de ingeniería del software. Proporcione cinco ejemplos para 
1lustrar que es cierto. 


3.5, Repase el libro de Weinberg [WEI86] y escriba un resu- 
men de dos o tres páginas de los aspectos que deberían tener- 
se en cuenta al aplicar el modelo MOL. 


3.6. Se le ha nombrado gestor de proyecto dentro de una 
organización de sistemas de información. Su trabajo es cons- 
truir una aplicación que es bastante similar a otras que ha cons- 
truido su equipo, aunque ésta es mayor y más compleja. Los 
requisitos han sido detalladamente documentados por el clien- 
te. ¿Qué estructura de equipo elegiría y por qué? ¿Qué mode- 
lo(-de proceso de software elegiría y por qué? 

3:71, Sele ha nombrado gestor de proyecto de una pequeña 
compañía de productos software. Su trabajo consiste en cons- 
truir un producto innovador que combine hardware de reali- 
dad virtual con software innovador. Puesto que la competencia 


por el mercado de entretenimiento casero es intensa, hay cier- 
ta presión para terminar el trabajo rápidamente. ¿Qué estruc- 
tura de equipo elegiría y por qué? ¿Qué modelo(s) de proceso 
de software elegiría y por qué? 

3.8. Sele ha nombrado gestor de proyecto de una gran com- 
pañía de productos software. Su trabajo consiste en dirigir la 
versión de la siguiente generación de su famoso procesador 
de textos. Como la competencia es intensa, se han estableci- 
do y anunciado fechas límite rígidas. ¿Qué estructura de equi- 
po elegiría y por qué? ¿Qué modelo(s) de proceso de software 
elegiría y por qué? 

3.9. Sele ha nombrado gestor de proyecto de software de una 
compañía que trabaja en el mundo de la ingeniería genética. 
Su trabajo es dirigir el desarrollo de un nuevo producto de soft- 
ware que acelere el ritmo de impresión de genes. El trabajo es 
orientado a 1+D, pero la meta es fabricar el producto dentro del 
siguiente año. ¿Qué estructura de equipo elegiría y por qué? 
¿Qué modelo(s) de proceso de software elegiría y por qué? 
3.10. Como muestra la Figura 3.1, basándose en los resulta- 
dos de dicho estudio, los documentos parecen tener más uso 
que valor. ¿Por qué cree que pasó esto y qué se puede hacer 
para mover el punto documentos por encima de la línea de 
regresión en el gráfico? Es decir, ¿qué se puede hacer para 
mejorar el valor percibido de los documentos? 

3.11. Se le ha pedido que desarrolle una pequeña aplicación 
que analice todos los cursos ofrecidos por la universidad e 
informe de las notas medias obtenidas en los cursos (para un 
periodo determinado). Escriba una exposición del alcance que 
abarca este problema. 

3.12. Haga una descomposición funcional de primer nivel 
de la función diseño de página tratado brevemente en la 
Sección 3.3.2. 


Una excelente serie de cuatro volúmenes escrito por Wein- 
berg (Quality Software Management, Dorset House, 1992, 
1993,1994,19096)introduce los conceptos básicos sobre sis- 
temas y conceptos de gestión, explica cómo usar medicio- 
nes eficazmente y menciona la «acción congruente», la 
habilidad de «encajar» las necesidades del gestor, del per- 
sonal técnico y las del negocio. Proporciona información 
Útil tanto a los gestores noveles como a los experimentados. 
Brooks (The Mythical Man-Month, Aniversary Edition, 
Addison-Wesley, 1995) ha actualizado su clásico libro para 
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proporcionar una nueva visión profunda de los aspectos del 
proyecto de software y de su gestión. Purba y Shah (How to 
Manage a Successful Software Project, Wiley, 1995)presen- 
tan un número de estudios de casos de proyectos que indican 
por qué unos fracasaron y otros fueron un éxito. Bennatan 
(Software Project Management in a Client/Server Environ- 
ment, Wiley, 1995) estudia aspectos específicos de gestión 
asociados con el desarrollo de sistemas cliente/servidor. 

Se puede argumentar que el aspecto más importante de la 
gestión del proyecto de software es la gestión de personal. El 
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libro definitivo sobre este tema lo escribieron DeMarco y Lis- 
ter [DEM98], pero se han publicado en los Ultimos años los 
siguientes libros donde se examina su importancia: 

Beaudouin-Lafon, M., Computer Supported Coopera- 
tive Work, Wiley-Liss, 1999. 

Carmel, E., Global Software Teams: Collaborating 
Across Borders and Time Zones, Prentice Hall, 1999. 

Humphrey, W. S., Managing Technical People: Inno- 
vation, Teamwork, and the Software Process, Addison-Wes- 
ley 1997. 

Humphrey, W. S., Introduction to the Team of Software 
Process, Addison-Wesley, 1999. 

Jones, P, H., Handbook of Team Design: A Practitio- 
ner's Guide to Team Systems Development, McGraw-Hill, 
1997. 

Karolak, D. $., Global Software Development: Mana- 
ging Virtual Teams and Environments, IEEE Computer 
Society, 1998. 

Mayer, M., The Virtual Edge: Embracing Technology 

for Distributed Project Team Success, Project Management 
Institute Publications, 1999. 

Otro excelente libro de Weinberg [WEI86] es lectura 
obligada para todo gestor de proyecto y jefe de equipo. Le 
dará una visión interna y directrices para realizar su traba- 
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jo más eficazmente. House (The Human Side df Project 
Management, Addison-Wesley, 1988) y Crossby (Running 
Things: The art of Making Things Happen, McGraw-Hill, 
1989) proporcionan directrices prácticas para gestores que 
deban tratar con problemas humanos y técnicos. 

Aunque no están relacionados específicamente con el 
mundo del software, y algunas veces sufren demasiadas 
simplificaciones y amplias generalizaciones, los libros de 
gran éxito de Drucker (ManagementChallenges for the 21st 
Century, Harperbusines, 1999), Buckingham y Coffman 
(First, Break All the Rules: What the World's Greatest 
Managers Do Differently, Simon $ Schuster, 1999) y Chris- 
tensen (The Innovator's Dilemma, Harvard Business School 
Press, 1997) enfatizan «nuevas reglas» definidas por una 
economía que cambia con rapidez. Viejos títulos como The 
One Minute Manager e In Search of Excellence continúan 
proporcionando enfoques valiosos que pueden ayudarle a 
gestionar los temas relacionados con el personal de un modo 
más eficiente. 


En Internet están disponibles una gran variedad de fuen- 
tes de información relacionadas con temas de gestión de pro- 
yectos de software. Se puede encontrar una lista actualizada 
con referencias a sitios (páginas) web que son relevantes para 
los proyectos de software en http://www.pressman5.com. 
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CAPÍTULO 


PROCESO DE SOFTWARE 
Y MÉTRICAS DE PROYECTOS 


A medición es fundamental para cualquier disciplina de ingeniería, y la ingeniería del soft- 
ware no es una excepción. La medición nos permite tener una visión más profunda propor- 
cionando un mecanismo para la evaluación objetiva. Lord Kelvin en una ocasión dijo: 

Cuando pueda medir lo que está diciendo y expresarlo con números, ya conoce algo sobre 
ello; cuando no pueda medir, cuando no pueda expresar lo que dice con números, su conoci- 
miento es precario y deficiente: puede ser el comienzo del conocimiento, pero en sus pensa- 
mientos, apenas está avanzando hacia el escenario de la ciencia. 

La comunidad de la ingeniería del software ha comenzado finalmente a tomarse en serio las 
palabras de Lord Kelvin. Pero no sin frustraciones y sí con gran controversia. 

Las métricas del software se refieren a un amplio elenco de mediciones para el software de 
computadora. La medición se puede aplicar al proceso del software con el intento de mejorar- 
lo sobre una base continua. Se puede utilizar en el proyecto del software para ayudar en la esti- 
mación, el control de calidad, la evaluación de productividad y el control de proyectos. 
Finalmente, el ingeniero de software puede utilizar la medición para ayudar a evaluar la cali- 
dad de los resultados de trabajos técnicos y para ayudar en la toma de decisiones táctica a medi- 
da que el proyecto evoluciona. 


VISTAZO RÁPIDO 


¿Qué es? El proceso del software y las 
métricas del producto son una medida 
cuantitativa que permite ala gente del 
software tener una visión profunda de 
la eficaciadel proceso del software y de 
los proyectos que dirigen utilizando el 
proceso como un marco de trabajo. Se 
reúnen los datos básicos de calidad y 
productividad. Estos datos son entonces 
analizados, comparados con promedios 
anteriores, y evaluados para determi- 
nar las mejoras en la calidad y produc- 
tividad. Las métricas son también 
utilizadas para señalar áreas con pro- 
blemas de manera que sepuedan desa- 
rrollarlos remedios y mejorar el proceso 
del software. 


¿Quién lo hace? Las métricas del soft- 
ware son analizadas y evaluadas por 
los administradores del software. A 
menudo las medidas son reunidas por 
los ingenieros del software. 

¿Por qué es importente? Si no mides, 
sólo podrás juzgar basándote en una 
evaluación subjetiva. Mediante la medi- 
ción, se pueden señalarlas tendencias 
(buenaso malas), realizar mejores esti- 
maciones, llevar a cabo una verdadera 
mejora sobre el tiempo. 

¿Cuáles son los pasos? Comenzar defi- 
niendo un conjunto limitado de medi- 
das de procesos, proyectos y productos 
que sean fáciles de recoger. Estas medi- 
das son a menudo normalizadas utili- 


zando métricas orientadas al tamaño o 
a la función. El resultado se analiza y 
se compara con promedios anteriores 
de proyectos similares realizados con 
la organización. Se evalúan las ten- 
dencias y se generan las conclusiones. 

¿Cuál es el producto obtenido?Es un 
conjunto de métricas del software que 
proporcionan una visión profunda del 
proceso y de la comprensión del pro- 
yecto. 


¿Cómo puedo estar seguro de que lo 
he hecho correctamente? Aplican- 
do un plan de medición sencillo pero 
consistente, que nunca utilizaremos 
para evaluar, premiar ocastigar elren- 
dimiento individual. 


Dentro del contexto de la gestión de proyectos de software,en primer lugar existe una gran pre- 
ocupación por las métricas de productividad y de calidad — medidas «de salida» (finalización) del 
desarrollo del software, basadas en el esfuerzo y tiempo empleados, y medidas de la «utilidad» del 
producto obtenido—, 

Park, Goethert y Florac [PAR96] tratan en su guía de la medición del software las razones por 
las que medimos: 

Hay cuatro razones para medir los procesos del software, los productos y los recursos: 

* caracterizar 

» evaluar 

* predecir 

» mejorar 
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Caracterizamos para comprender mejor los procesos, los productos, los recursos y los entornos y para establecer 
las líneas base para las comparaciones con evaluaciones futuras. 

Evaluamos para determinar el estado con respecto al diseño. Las medidas utilizadas son los sensores que nos per- 
miten conocer cuándo nuestros proyectos y nuestros procesos están perdiendo la pista, de modo que podamos poner- 
los bajo control. También evaluamos para valorar la consecución de los objetivos de calidad y para evaluar el impacto 
de la tecnología y las mejoras del proceso en los productos y procesos. 

Predecimos para poder planificar. Realizar mediciones para la predicción implica aumentar la comprensión de las 
relaciones entre los procesos y los productos y la construcción de modelos de estas relaciones, por lo que los valores 
que observamos para algunos atributos pueden ser utilizados para predecir otros. Hacemos esto porque queremos esta- 
blecer objetivos alcanzables para el coste, planificación, y calidad - d emanera que se puedan aplicar los recursos apro- 
piados —. Las medidas de predicción también son la base para la extrapolación de tendencias, con lo que la estimación 
para el coste, tiempo y calidad se puede actualizar basándose en la evidencia actual. Las proyecciones y las estima- 
ciones basadas en datos históricos también nos ayudan a analizar riesgos y a realizar intercambios diseño/coste. 

Medimos para mejorar cuando recogemos la información cuantitativa que nos ayuda a identificar obstáculos, pro- 
blemas de raíz, ineficiencias y otras oportunidades para mejorar la calidad del producto y el rendimiento del proceso. 


Aunque los términos medida, medición y métricas se [RAG95]. Un indicador proporciona una visión pro- 
utilizan a menudo indistintamente, es importante des- funda que permite al gestor de proyectos o a los inge- 
tacar las diferencias sutiles entre ellos. Como los tér-—  nieros de software ajustar el producto, el proyecto o 
minos «medida» y «medición» se pueden utilizar el proceso para que las cosas salgan mejor. 


como un nombre o como un verbo, las definiciones 
de estos términos se pueden confundir. Dentro del con- 
texto de la ingeniería del software, una medida pro- 
porciona una indicación cuantitativa de la extensión, 
cantidad, dimensiones, capacidad o tamaño de algu- 
nos atributos de un proceso o producto. La medición 
es el acto de determinar una medida. El JEEE Stan- 
dard Glossary of Software Engineering Terms [IEEE93] 
define métrica como «una medida cuantitativa del gra- 
do en que un sistema, componente o proceso posee 


lb que se puede contor cuento, y no todo 
to se puede contar. 


un atributo dado». Por ejemplo, cuatro equipos de software están tra- 
Cuando, simplemente, se ha recopilado un solo bajando en un proyecto grande de software. Cada equi- 
aspecto de los datos (por ejemplo: el número de erro- po debe conducir revisiones del diseño, pero puede 


res descubiertos en la revisión de un módulo), seha seleccionar el tipo de revisión que realice. Sobre el 
establecido una medida. La medición aparece como examen de la métrica, errores encontrados por per- 
resultado de la recopilación de uno o varios aspectos  sona-hora consumidas, el gestor del proyecto notifi- 
de los datos (por ejemplo: se investiga un número de ca que dos equipos que utilizan métodos de revisión 
revisiones de módulos para recopilar medidas del más formales presentan un 40 por 100 más de erro- 


número de errores encontrados durante cada revisión). res encontrados por persona-hora consumidas que 
Una métrica del software relata de alguna forma las otros equipos. Suponiendo que todos los parámetros 
medidas individuales sobre algún aspecto (por ejem- son iguales, esto proporciona al gestor del proyecto 
plo: el número medio de errores encontrados por revi-- un indicador en el que los métodos de revisión más 
sión o el número medio de errores encontrados por formales pueden proporcionar un ahorro mayor en 
persona y hora en revisiones”). inversión de tiempo que otras revisiones con un enfo- 

Un ingeniero del software recopila medidas y desa- que menos formal. Esto puede sugerir que todos los 
rrolla métricas para obtener indicadores. Un indica- equipos utilicen el enfoque más formal. La métrica 
dor es una métrica o una combinación de métricas que proporciona al gestor una visión más profunda. Y ade- 
proporcionan una visión profunda del proceso del soft- más le llevará a una toma de decisiones más funda- 


ware, del proyecto de software o del producto en sí mentada. 


' Esto asume que se recopila otra medida, persona y horas gastadas 
en cada revisión. 
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La medición es algo común en el mundo de la ingenie- 
ría. Se mide el consumo de energía, el peso, las dimen- 
siones físicas, la temperatura, el voltaje, la relación 
señal-ruido... la lista es casi interminable. Por desgra- 
cia, la medición es mucho menos común en el mundo 
de la ingeniería del software. Existen problemas para 
ponerse de acuerdo sobre qué medir y las medidas de 
evaluación de problemas recopilados. 


Referencia Web 


Se puede descargar una guío completo 
de métricos del software desde: 


www.inv.nasa.gov /SWG /resources/ 
NASA-GB-001-94.pdf 


Se deberían recopilar métricas para que los indica- 
dores del proceso y del producto puedan ser ciertos. Los 
indicadores de proceso permiten a una organización de 
ingeniería del software tener una visión profunda de la 
eficacia de un proceso ya existente (por ejemplo: el para- 
digma, las tareas de ingeniería del software, productos 
de trabajo e hitos). También permiten que los gestores 
evalúen lo que funciona y lo que no. Las métricas del 
proceso se recopilan de todos los proyectos y durante 
un largo período de tiempo. Su intento es proporcionar 
indicadores que lleven a mejoras de los procesos de soft- 
vare a largo plazo. 

Los indicadores de proyecto permiten al gestor de 
proyectos del software (1) evaluar el estado del proyecto 
en curso; (2) seguir la pista de los riesgos potenciales: 
(3) detectar las áreas de problemas antes de que se con- 
viertan en «críticas»; (4) ajustar el flujo y las tareas del 
trabajo, y (5)evaluar la habilidad del equipo del pro- 
yecto en controlar la calidad de los productos de traba- 
jo del software. 


Producto 


Condiciones 
del negocio 


Características 
del cliente 


Personas Tecnología 


Entorno 
de desarrollo 


FIGURA 4.1. Determinantes de la calidad del software 
y de la efectividad de organización 
(adaptado según [PAU94]). 
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CAPÍTULO 4 PROCESO DEL SOFTWARE Y MÉTRICAS DEL PROYECTO 


En algunos casos, se pueden utilizar las mismas 
métricas del software para determinar tanto el pro- 
yecto como los indicadores del proceso. En realidad, 
las medidas que recopila un equipo de proyecto y las 
convierte en métricas para utilizarse durante un pro- 
yecto también pueden transmitirse a los que tienen la 
responsabilidad de mejorar el proceso del software. 
Por esta razón, se utilizan muchas de las mismas métri- 
cas tanto en el dominio del proceso como en el del 
proyecto. 


4.2.1. Métricas del proceso y mejoras 
en el proceso del software 


La Única forma racional de mejorar cualquier proceso 
es medir atributos del proceso, desarrollar un juego de 
métricas significativas según estos atributos y entonces 
utilizar las métricas para proporcionar indicadores que 
conducirán a una estrategia de mejora. Pero antes de 
estudiar las métricas del software y su impacto en la 
mejoras de los procesos del software es importante des- 
tacar que el proceso es el Único factor de «los controla- 
bles al mejorar la calidad del software y su rendimiento 
como organización» [PAU9A4]. 


CLAVE 


La habilidad y la motivación del personal realizando 
el trabajo son los factores más importantes que influyen 
en lo calidad del software. 


En la Figura 4.1, el proceso se sitúa en el centro de 
un triángulo que conecta tres factores con una pro- 
funda influencia en la calidad del software y en el ren- 
dimiento como organización. La destreza y la 
motivación del personal se muestran como el Unico 
factor realmente influyente en calidad y en el rendi- 
miento [BOE81]. La complejidad del producto pue- 
de tener un impacto sustancial sobre la calidad y el 
rendimiento del equipo. La tecnología (por ejemplo: 
métodos de la ingeniería del software) que utiliza el 
proceso también tiene su impacto. Además, el trián- 
gulo de proceso existe dentro de un círculo de condi- 
ciones de entornos que incluyen entornos de desarrollo 
(por ejemplo: herramientas CASE), condiciones de 
gestión (por ejemplo: fechas tope, reglas de empresa) 
y Características del cliente (por ejemplo: facilidad de 
comunicación). 


Ñ ¿Como puedo medir 
la efectividad de un proceso 
de software? 


www.elsolucionario.net 


INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRÁCTICO 


La eficacia de un proceso de software se mide indi- 
rectamente. Esto es, se extrae unjuego de métricas según 
los resultados que provienen del proceso. Entre los resul- 
tados se incluyen medidas de errores detectados antes 
de la entrega del software, defectos detectados e infor- 
mados a los usuarios finales, productos de trabajo entre- 
gados (productividad), esfuerzo humano y tiempo 
consumido, ajuste con la planificación y otras medidas. 
Las métricas de proceso también se extraen midiendo 
las características de tareas específicas de la ingeniería 
del software. Por ejemplo, se podría medir el tiempo y 
el esfuerzo de llevar a cabo las actividades de protec- 
ción y las actividades genéricas de ingeniería del soft- 
ware del Capítulo 2. 

Grady [GRA92] argumenta que existen unos usos 
«privados y públicos» para diferentes tipos de datos 
de proceso. Como es natural que los ingenieros del 
software pudieran sentirse sensibles ante la utiliza- 
ción de métricas recopiladas sobre una base particu- 
lar, estos datos deberían serprivados para el individuo 
y servir sólo como un indicador de ese individuo. 
Entre los ejemplos de métricas privadas se incluyen: 
índices de defectos (individualmente), índices de 
defectos (por módulo), errores encontrados durante el 
desarrollo. 

La filosofía de «datos de proceso privados» se ajus- 
ta bien con el enfoque del proceso personal del soft- 
ware propuesto por Humphrey [HUM95]. Humphrey 
describe el enfoque de la manera siguiente: 


El proceso personal del software (PPS) es un conjunto 
estructurado de descripciones de proceso, mediciones y méto- 
dos que pueden ayudar a que los ingenieros mejoren su rendi- 
miento personal. Proporcionan las formas, guiones y estándares 
que les ayudan a estimar y planificar su trabajo. Muestra cómo 
definirprocesos y cómo medir su calidad y productividad. Un 
principio PPS fundamental es que todo el mundo es diferente 
y que un método que sea efectivo para un ingeniero puede que 
no sea adecuado para otro. Así pues, el PPS ayuda a que los 
ingenieros midan y sigan la pista de su trabajo para que pue- 
dan encontrar los métodos que sean mejores para ellos. 


Humphrey reconoce que la mejora del proceso del 
software puede y debe empezar en el nivel individual. 
Los datos privados de proceso pueden servircomo refe- 
rencia importante para mejorar el trabajo individual del 
ingeniero del software. 

Algunas métricas de proceso son privadas para el 
equipo del proyecto de software, pero públicas para 
todos los miembros del equipo. Entre los ejemplos se 
incluyen los defectos informados de funciones impor- 
tantes del software (que un grupo de profesionales han 
desarrollado), errores encontrados durante revisiones 
técnicas formales, y líneas de código o puntos de fun- 
ción por módulo y función”. El equipo revisa estos datos 
para detectar los indicadores que pueden mejorar el ren- 
dimiento del equipo. 


? Consulte las Secciones 4.3.1 y 4.3.2 para estudios más detallados 
sobre LDC (líneasde código) y métricas de puntos de función. 
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las métricas públicas permiten a una organización 
realizar cambios estratégicos que mejoran el proceso 
del software y cambios tácticos durante un proyecto 
de software. 


Las métricas públicas generalmente asimilan infor- 
mación que originalmente era privada de particulares y 
equipos. Los índices de defectos a nivel de proyecto (no 
atribuidos absolutamente a un particular), esfuerzo, tiem- 
po y datos afines se recopilan y se evalúan en un inten- 
to de detectar indicadores que puedan mejorar el 
rendimiento del proceso organizativo. 

Las métricas del proceso del software pueden pro- 
porcionar beneficios significativos a medida que una 
organización trabaja por mejorar su nivel global de 
madurez del proceso. Sin embargo, al igual que todas las 
métricas, éstas pueden usarse mal, originando más pro- 
blemas de los que pueden solucionar. Grady [GRA92] 
sugiere una «etiquetade métricas del software» adecua- 
da para gestores al tiempo que instituyen un programa 
de métricas de proceso: 

» Utilice el sentido común y una sensibilidad organi- 
zativa al interpretar datos de métricas. 

+ Proporcione una retroalimentación regular para par- 
ticulares y equipos que hayan trabajado en la reco- 
pilación de medidas y métricas. 

»  Noutilice métricas para evaluar a particulares. 

» Trabaje con profesionales y equipos para establecer 
objetivos claros y métricas que se vayan a utilizar 
para alcanzarlos. 

+ Noutilice nunca métricas que amenacen a particu- 
lares O equipos. 

+ Los datos de métricas que indican un área de proble- 
mas no se deberían considerar «negativos». Estos datos 
son meramente un indicador de mejora de proceso. 

» No se obsesione con una sola métrica y excluya otras 
métricas importantes. 


Qué directrices deben 
aplicarse cuando recogemos 
métricas del software? 


A medida que una organización está más a gusto con 
la recopilación y utiliza métricas de proceso, la deriva- 
ción de indicadores simples abre el camino hacia un 
enfoque más riguroso llamado mejora estadística de 
proceso del software (MEPS).En esencia, MEPS utili- 
za el análisis de fallos del software para recopilar infor- 


www.elsolucionario.net 


a 3 

mación de errores y defectos” encontrados al desarro- 
llar y utilizar una aplicación de sistema o producto. El 
análisis de fallos funciona de la misma manera: 


Referencia Web] s 


MPSE y otra información relacionadacon la calidad 
está, disponible en la Sociedad Americana para la Calidad 
en WWW.asq.org 


1, Todos los errores y defectos se categorizan por ori- 
gen (por ejemplo: defectos en la especificación, en 
la lógica, no acorde con los estándares). 


N 


Se registra tanto el coste de corregir cada error como 
el del defecto. 


3. El número de errores y de defectos de cada catego- 
ría se cuentan y se ordenan en orden descendente. 


. Se computa el coste global de errores y defectos de 
cada categoría. 


5. Los datos resultantes se analizan para detectar las 
categorías que producen el coste más alto para la 
organización. 

. Se desarrollan planes para modificar el proceso con 
el intento de eliminar (o reducir la frecuencia de apa- 
riciones de) la clase de errores y defectos que sean 
más costosos. 


Manejo de datos 


Interfaz software 10.9% 


6.0% 
Estándares 
Interfaz 6.9% 
hardware 
7.7% 


Comprobación 
de errores 


10.9% LS 
Especificaciones 


25.5% 
Interfaz de usuario 


11.7% 
Origen de errores/defectos 


O] Especificación/requisitos 
[] Diseño 
E Código 
FIGURA 4.2. Causas de defectos y su origen para cuatro 
proyectos de software [GRA94], 


3 Como se trata en el Capítulo 8, un errores alguna fisura en un pro- 
ducto de trabajo de ingeniería del software o en la entrega descu- 
bierta por los ingenieros del software antes de que el software sea 
entregado al usuario final. 

Un defecto es una fisura descubierta después de la entrega al usua- 
no final. 
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Cionsuofh 


No puedes mejoror tu enfoque para la ingeniería 
del software a menos que comprendos donde estás 
fuerte y donde estás débil. Utilice los técnicas MÉPS 
poro aumentar esa comprensión. 


Siguiendo los pasos 1 y 2 anteriores, se puede desa- 
rrollar una simple distribución de defectos (Fig. 4.2) 
[GRA94]. Para el diagrama de tarta señalado en la figu- 
ra, se muestran ocho causas de defectos y sus ongenes 
(indicados en sombreado). Grady. sugiere el' desarrollo 
de un diagrama de espina [GRA92] para ayudar a diag- 
nosticar los datos presentados en el diagrama de fre- 
cuencias. En la Figura 4.3 la espina del diagrama (la línea 
central) representa el factor de calidad en consideración 
(en este caso, los defectos de especificación que cuentan 
con el 25 por 100 del total). Cada una de las varillas (líne- 
as diagonales) conectadas a la espina central indican una 
causa potencial del problema de calidad (por ejemplo: 
requisitos perdidos, especificación ambigua, requisitos 
incorrectos y requisitos cambiados). La notación de la 
espina y de las varillas se añade entonces a cada una de 
las varillas principales del diagrama para centrarse sobre 
la causa destacada. La expansión se muestra sólo para la 
causa «incorrecta» en la Figura 4.3. 

La colección de métricas del proceso es el conduc- 
tor para la creación del diagrama en espina. Un diagra- 
ma en espina completo se puede analizar para extraer 
los indicadores que permitan a una organización de soft- 
ware modificar su proceso para reducir la frecuencia de 
errores y defectos. 


Perdido 


Ambiguo 


Defectos de 

especificación 
.. 

Cliente equivocado consultado 


El cliente dió 
información 
equivocada 


Peticiones inadecuadas 


Información 
anticuada utilizada 


Cambios 
FIGURA 4.3. Un diagrama de espina (Adaptado de [GRA92]). 


Incorrecto 
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4.2.2, Métricas del proyecto 


Las métricas del proceso de software se utilizan para 
propósitos estratégicos. Las medidas del proyecto de 
software son tácticas. Esto es, las métricas de proyec- 
tos y los indicadores derivados de ellos los utilizan un 
gestor de proyectos y un equipo de software para adap- 
tar el flujo del trabajo del proyecto y las actividades 
técnicas. 


Referencia cruzada 


las técnicas de estimación de proyectos se estudian 
en el capítulo 5. 


La primera aplicación de métricas de proyectos en 
la mayoría de los proyectos de software ocurre duran- 
te la estimación. Las métricas recopiladas de proyectos 
anteriores se utilizan como una base desde la que se rea- 
lizan las estimaciones del esfuerzo y del tiempo para el 
actual trabajo del software. A medida que avanza un 
proyecto, las medidas del esfuerzo y del tiempo consu- 
mido se comparan con las estimaciones originales (y la 
planificación de proyectos). El gestor de proyectos uti- 
liza estos datos para supervisar y controlar el avance. 

A medida que comienza el trabajo técnico, otras 
métricas de proyectos comienzan a tener significado. 
Se miden los índices de producción representados 
mediante páginas de documentación, las horas de revi- 
sión, los puntos de función y las líneas fuente entre- 
gadas. Además, se sigue la pista de los errores 
detectados durante todas las tareas de ingeniería del 
software. Cuando va evolucionando el software des- 
de la especificación al diseño, se recopilan las métri- 
cas técnicas (Capítulos 19 al 24) para evaluar la 
calidad del diseño y para proporcionar indicadores 
que influirán en el enfoque tomado para la generación 
y prueba del código. 


La utilización de métricas para el proyecto tiene dos 
aspectos fundamentales. En primer lugar, estas métri- 
cas se utilizan para minimizar la planificación de desa- 
rrollo haciendo los ajustes necesariosque eviten retrasos 
y reduzcan problemas y riesgos potenciales. En segun- 
do lugar, las métricas para el proyecto se utilizan para 
evaluar la calidad de los productos en el momento actual 
y cuando sea necesario, modificando el enfoque técni- 
co que mejore la calidad. 


Cómo debemos 
utilizar las métricas 
durante el proyecto? 


A medida que mejora la calidad, se minimizan los 
defectos, y al tiempo que disminuye el número de defec- 
tos, la cantidad de trabajo que ha de rehacerse también 
se reduce. Esto lleva a una reducción del coste global 
del proyecto. 

Otro modelo de métricas del proyecto de software 
[HET93] sugiere que todos los proyectos deberían medir: 


+ entradas: la dimensión de los recursos (p. ej.: perso- 
nas, entorno) que se requieren para realizarel trabajo, 


+ salidas: medidas de las entregas o productos creados 
durante el proceso de ingeniería del software, 


+ resultados: medidas que indican la efectividad de las 
entregas. 

En realidad, este modelo se puede aplicar tanto al 
proceso como al proyecto. En el contexto del proyecto, 
el modelo se puede aplicar recursivamente a medida 
que aparece cada actividad estructural. Por consiguien- 
te las salidas de una actividad se convierten en las entra- 
das de la siguiente. Las métricas de resultados se pueden 
utilizar para proporcionar una indicación de la utilidad 
de los productos de trabajo cuando fluyen de una acti- 
vidad (0 tarea) a la siguiente. 


Las mediciones del mundo físico se pueden categorizar 
de dos maneras; medidas directas (por ejemplo: la lon- 
gitud de un tomillo) y medidas indirectas (por ejemplo: 
la «calidad» de los tomillos producidos, medidos con- 
tando los artículos defectuosos). Las métricas del soft- 
ware se pueden categorizar de forma similar. 

Entre las medidas directas del proceso de la inge- 
niería del software se incluyen el coste y el esfuerzo 
aplicados. Entre las medidas directas del producto se 
incluyen las líneas de código (LDC) producidas, velo- 
cidad de ejecución, tamaño de memoria, y los defectos 
informados durante un período de tiempo establecido. 
Entre las medidas indirectas se incluyen la funcionali- 
dad, calidad, complejidad, eficiencia, fiabilidad, facili- 
dad de mantenimiento y muchas otras «capacidades» 
tratadas en el Capítulo 19. 
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¿Cuál es la diferencia 
entre medidas directas 


e indirectas? 


El coste y el esfuerzorequerido para construirel soft- 
ware, el número de líneas de código producidas, y otras 
medidas directas son relativamente fáciles de reunir, 
mientras que los convenios específicos para la medición 
se establecen más adelante. Sin embargo, la calidad y 
funcionalidad del software, o su eficiencia O manteni- 
miento son más difíciles de evaluar y sólo pueden ser 
medidas indirectamente. 

El dominio de las métricas del software se dividen 
en métricas de proceso, proyecto y producto. También 
se acaba de destacar que las métricas de producto que 
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son privadas para un individuo a menudo se combinan 
para desarrollar métricas del proyecto que sean públi- 
cas para un equipo de software. Las métricas del pro- 
yecto se consolidan para crear métricas de proceso que 
sean públicas para toda la organización del software. 
Pero jcómo combina una organización métricas que 
provengan de particulares o proyectos? 


Cons) 


Puesto que muchos factores influyen en el trabajo 
del software, no utilice las métricas poro comparar 
personas O equipos. 


Para ilustrarlo, se va a tener en consideración un 
ejemplo sencillo. Personas de dos equipos de proyecto 
diferentes registran y categorizan todos los errores que 
se encuentran durante el proceso del software. Las medi- 
das de las personas se combinan entonces para desa- 
rrollar medidas de equipo. El equipo A encontró 342 
errores durante el proceso del software antes de su rea- 
lización. El equipo B encontró1 84. Considerando que 
en el resto los equipos son iguales, ¿qué equipo es más 
efectivo en detectar errores durante el proceso'? Como 
no se conoce el tamaño o la complejidad de los proyec- 
tos, no se puede responder a esta pregunta. Sin embar- 
go, si se normalizan las medidas, es posible crear 
métricas de software que permitan comparar medidas 
más amplias de otras organizaciones. 


4.3.1. Métricas Orientadas al Tamaño 


Las métricas del software orientadas al tamaño provie- 
nen de la normalización de las medidas de calidad y/o 
productividad considerando el «tamaño» del software 
que se haya producido. Si una organización de softwa- 
re mantiene registros sencillos, se puede crear una tabla 
de datos orientados al tamaño, como la que muestra la 
Figura 4.4. La tabla lista cada proyecto de desarrollo de 
software de los últimos años y las medidas correspon- 
dientes de cada proyecto. Refiriéndonos a la entrada de 
la tabla (Fig. 4.4) del proyecto alfa: se desarrollaron 
12.100líneas de código (LDC) con 24 personas-mes y 
con un coste de E168.000. Debe tenerse en cuenta que 
el esfuerzo y el coste registrados en la tabla incluyen 
todas las actividades de ingeniería del software (análi- 
sis, diseño, codificación y prueba) y no sólo la codifi- 
cación. Otra información sobre el proyecto alfa indica 
que se desarrollaron 365 páginas de documentación, se 
registraron 134 errores antes de que el software se entre- 
gara y se encontraron 29 errores después de entregár- 
selo al cliente dentro del primer año de utilización. 
También sabemos que trabajaron tres personas en el 
desarrollo del proyecto alfa. 
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¿Qué datos deberíamos 
reunir para derivar métricas 
orientadas al tamaño? 


Errores | Defectos ¡ Personas 


LDC ¡Esfuerzo| Coste | Pag. Doc. 


*royecto 


12,100 
27,200 
20,200 


FIGURA 4.4. Métricas orientadas al tamaño. 


Para desarrollar métricas que se puedan comparar 
entre distintos proyectos, se seleccionan las líneas de 
código como valor de normalización. Con los rudi- 
mentarios datos contenidos en la tabla se pueden desa- 
rrollar para cada proyecto un conjunto de métricas 
simples orientadas al tamaño: 

« errores por KLDC (miles de líneas de código) 


* defectos” por KLDC 
+ EporLDC 
+ páginas de documentación por KLDC 


Plantilla de colección de métricos 


Además, se pueden calcular otras métricas interesantes: 
» errores por persona-mes 
»  LDC por persona-mes 
. £ por página de documentación 


4.3.2. Métricas Orientadas a la Función 


Las métricas del software orientadas a la función utili- 
zan una medida de la funcionalidad entregada por la 
aplicación como un valor de normalización. Ya que la 
«funcionalidad» no se puede medir directamente, se 
debe derivar indirectamente mediante otras medidas 
directas. Las métricas orientadas a la función fueron 
propuestas por primera vez por Albretch [ALB79], quien 
sugirió una medida llamadapunto defunción. Los pun- 
tos de función se derivan con una relación empírica 


4 Un defecto ocurre cuando las actividades de garantía de calidad (p. 
ej.: revisiones técnicas formales) fallan para descubrir un error en un 
producto de trabajo generado durante el proceso del software. 
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según las medidas contables (directas) del dominio de 
información del software y las evaluaciones de la com- 
plejidad del software. 


Se puede obtener información completo sobre los puntos 
defunción en. www.ifpug.org 


Los puntos de función se calculan [IFP94] comple- 
tando la tabla de la Figura 4.5. Se determinan cinco 
características de dominios de información y se pro- 
porcionan las cuentas en la posición apropiada de la 
tabla. Los valores de los dominios de información se 
definen de la forma siguiente? 


Número de entradas de usuario. Se cuenta cada 
entrada de usuario que proporciona diferentes datos 
orientados a la aplicación. Las entradas se deberían 
diferenciar de las peticiones, las cuales se cuentan de 
forma separada. 


a 
a 


CLAVE 


los puntos de función se derivan de medidas 
directas del dominio de la información. 


Número de salidas de usuario. Se cuentacada salida 
que proporciona al usuario información orientada a la 
aplicación. En este contexto la salida se refiere a infor- 
mes, pantallas, mensajes de error, etc. Los elementos 
de datos particulares dentro de un informe no se cuen- 
tan de forma separada. 

Número de peticiones de usuario. Una petición se 
define como una entrada interactivaque produce la gene- 
ración de alguna respuesta del software inmediata en 
forma de salidainteractiva, Se cuentacada petición por 
separado. 

Número de archivos. Se cuenta cada archivo maes- 
tro lógico (estoes, un grupo lógico de datos que puede 
ser una parte de una gran base de datos o un archivo 
independiente). 

Número de interfaces externas. Se cuentan todas 
las interfaces legibles por la máquina (por ejemplo: 
archivos de datos de cinta o disco) que se utilizan 
para transmitir información a otro sistema. 


Una vez que se han recopilado los datos anterio- 
res, a la cuenta se asocia un valor de complejidad. 
Las organizaciones que utilizan métodos de puntos 
de función desarrollan criterios para determinar si 
una entrada en particular es simple, media o com- 
pleja. No obstante la determinación de la compleji- 
dad es algo subjetiva. 


5 En realidad, la definición de los valores del dominio de la informa- 
ción y la forma en que se cuentan es un poco más complejo. El lec- 
tor interesado debería consultar [IFP94] para obtener más detalles. 
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Factor de ponderación 
Parámetros 
de medición 


Cuenta Simple Medio Complejo 


Número 
de entradas 
de usuario 


Número 
de salidas 
de usuario 


Número 
de peticiones 
de usuario 


Número 
de archivos 


Número 
de interfaces 
externas 


DODOO 
DODOO 


Cuenta total 


FIGURA 4.5. Cálculo de puntos de función. 


Para calcular puntos de función (PF), se utiliza la 
relación siguiente: 


PF = cuenta-total x [0,65 +0,01 x 6(F)) (4.1) 


en donde cuenta-total es la suma de todas las entradas 
PF obtenidas de la figura 4.5. 

F; (i=1 a 14) son «valores de ajuste de la compleji- 
dad» según las respuestas a las siguientes preguntas 
[ART85]: 

1. ¿Requiere el sistema copias de seguridad y de recu- 
peración fiables? 
¿Se requiere comunicación de datos? 
. ¿Existen funciones de procesamiento distribuido? 
. ¿Es crítico el rendimiento? 


¿Se ejecutará el sistema en un entorno operativo 
existente y fuertemente utilizado? 


. ¿Requiere el sistema entrada de datos interactiva? 


. ¿Requiere la entrada de datos interactiva que las 
transacciones de entrada se lleven a cabo sobre múl- 
tiples pantallas u operaciones? 


. ¿Se actualizan los archivos maestros de forma 
interactiva? 


¿Son complejas las entradas, las salidas, los archi- 
vos O las peticiones? 
¿Es complejo el procesamiento interno? 

. ¿Se ha diseñado el código para ser reutilizable? 

. ¿Están incluidas en el diseño la conversión y la ins- 
talación'? 

. ¿Se ha diseñado el sistema para soportar múltiples 
instalaciones en diferentes organizaciones? 


. ¿Se ha diseñado la aplicación para facilitar los cam- 
bios y para ser fácilmente utilizada por el usuario? 


www.elsolucionario.net 


Cada una de las preguntas anteriores es respondida 
usando una escala con rangos desde O (no importante o 
aplicable) hasta 5 (absolutamente esencial). Los valo- 
res constantes de la ecuación (4.1) y los factores de peso 
que se aplican a las cuentas de los dominios de infor- 
mación se determinan empíricamente. 

Una vez que se han calculado los puntos de función, 
se utilizan de forma análoga a las LDC como forma de 
normalizar las medidas de productividad, calidad y otros 
atributos del software. 


4,3,3, Métricas ampliadas de punto de función 


La medida de punto de función se diseñó originalmen- 
te para aplicarse a aplicaciones de sistemas de infor- 
mación de gestión. Para acomodar estas aplicaciones, 
se enfatizó la dimensión de datos (los valores de domi- 
nios de información tratados anteriormente) para la 
exclusión de dimensiones (control) funcionales y de 
comportamiento. Por esta razón, la medida del punto de 
función era inadecuada para muchos sistemas de inge- 
niería y sistemas empotrados (que enfatizan función y 
control). Para remediar esta situación se ha propuesto 
un número de extensiones a la métrica del punto de fun- 
ción básica. 


e 
CLA VE 


la extensión de los puntos de función se utiliza 
en la ingeniería, en las aplicaciones de tiempo real 
y en las aplicaciones orientadas al control. 


Una extensión del punto de función es la llamada 
puntos de características [JON91]; es una ampliación 
de la medida del punto de función que se puede aplicar 
a sistemas y aplicaciones de ingeniería del software. La 
medida de punto de característica acomoda a aplica- 
ciones en donde la complejidad del algoritmo es alta. 
Las aplicaciones de software de tiempo real, de control 
de procesos, y empotradas tienden a tener alta comple- 
jidad de algoritmos y por lo tanto son adecuadas para 
el punto de característica. 

Para calcular el punto de característica, los valores 
de dominio de información se cuentan otra vez y se pesan 
de la forma que se describe en la Sección4.3.2. Además, 
la métrica del punto de característica cuenta una carac- 
terística nueva del software—-los algoritmos—. Un algo- 
ritmo se define como «un problema de cálculo limitado 
que se incluye dentro de un programa de computadora 
específico» [JON91]. Invertir una matriz, decodificar 
una cadena de bits o manejar una interrupción son ejem- 
plos de algoritmos. 


$ Debe señalarse que también han sido propuestas otras extensiones 
alos puntos de función para aplicarlas en trabajos de software de 
tiempo real (p.ej., [ALA97]). Sin embargo, ninguno de estos parece 
usarse ampliamente en la industria. 


61 


¡E Y MÉTRICAS DEL PROYECTO 


Referencia 


Se puede encontrar una lista Útil de preguntas realizadas 
con frecuencia sobre los puntos de función (y puntos 

de función extendidos) en: 

htip:/ /ourworld.compuserve.com/ 
homepages/softcomp/ 


Boeing ha desarrollado otra extensión de punto de 
función para sistemas en tiempo real y productos de 
ingeniería. El enfoque de Boeing integra la dimensión 
de datos del software con las dimensiones funciona- 
les y de control para proporcionar una medida orien- 
tada a la función que es adecuada a aplicaciones que 
enfatizan las capacidades de control y función. Las 
características de las tres dimensiones del software se 
«cuentan, cuantifican y transforman» en una medida 
que proporciona una indicación de la funcionalidad 
entregada por el software?, llamada Punto de Función 
3D [WHI95] 

La dimensión de datos se evalúa exactamente igual 
a como se describe en la Sección 4.3.2. Las cuentas de 
datos retenidos (la estructura interna de datos de pro- 
gramas, p. ej.: archivos) y los datos externos (entradas, 
salidas, peticiones y referencias externas) se utilizan a 
lo largo de las medidas de la complejidad para derivar 
una cuenta de dimensión de datos. 

La dimensión funcional se mide considerando «el 
número de operaciones internas requeridas para trans- 
formar datos de entrada en datos de salida» [WHI95]. 
Para propósitos de computación de los puntos de fun- 
ción 3D, se observa una «transformación» como una 
serie de pasos de proceso que quedan limitados por sen- 
tencias semánticas. La dimensión de control se mide 
contando el número de transiciones entre estados”. 

Un estado representa algún modo de comporta- 
miento externamente observable, y una transición ocu- 
rre como resultado de algún suceso que cambia el 
modo de comportamiento del sistema o del software 
(esto es, cambia el estado). Por ejemplo, un teléfono 
inalámbrico contiene software que soporta funciones 
de marcado automático. Para introducir el estado de 
marcado automático desde un estado en descanso, el 
usuario pulsa una tecla Auto en el teclado numérico. 
Este suceso hace que una pantalla LCD pida un códi- 
go que indique la parte que se llama. Con la entrada 
del código y pulsando la tecla de Marcado (otro suce- 
so), el software del teléfono inalámbrico hace una 
transición al estado de marcado. Cuando se compu- 
tan puntos de función 3D, no se asigna un valor de 
complejidad a las transiciones. 


7 En el capítulo 12 se presenta un estudio detallado de la dimensión 
de comportamientos que incluyen estados y transiciones de estados. 
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Para calcular puntos de función 3D, se utiliza la rela- 
ción siguiente: 


índice =1+ O+O0+F +E+T+R (4.2) 


en donde I, O, Q, E, E, T y R representan valores con 
peso de complejidad en los elementos tratados ante- 
riormente: entradas, salidas, peticiones, estructuras de 
datos internas, archivos externos, transformaciones y 
transiciones, respectivamente. Cada valor con peso de 
complejidad se calcula con la relación siguiente: 


valor con peso de complejidad = 


= Ny Wi NW ig Nip W iy, (4.3) 
en donde N;, ,N;¿ y N;, representan el número de apa- 
riciones del elemento ¡ (p. ej.: salidas) para cada nivel 
de complejidad (bajo, medio, alto), y W;¡ , Wi, y Wi, 
son los pesos correspondientes. El cálculo global de los 
puntos de función 3D se muestran en la Figura 4.6. 

Se debería señalar que los puntos de función, los pun- 
tos de característica y los puntos de función 3D repre- 
sentan lo mismo —«funcionalidad» o «utilidad» 
entregada por el software —. En realidad, cada una de 
estas medidas producen el mismo valor si sólo se con- 
sidera la dimensión de datos de una aplicación. Para sis- 
temas de tiemporeal más complejos, la cuenta de puntos 
de característica a menudo se encuentra entre el 20 y el 
35 por 100 más que la cuenta determinada sólo con los 
puntos de función. 


La relación entre las líneas de código y los puntos de fun- 
ción depende del lenguaje de programación que se utili- 
ce para implementarel software, y de la calidad del diseño. 
Ciertos estudios han intentado relacionar las métricas LDC 
y PF. Citando a Albrecht y Gaffney [A1.B83]: 


La tesis de este trabajo es que la cantidad de función pro- 
porcionada por la aplicación (programa) puede ser estimada 
por la descomposiciónde los principales componentes* de datos 
que usa o proporciona el programa. Además, esta estimación 
de la función debe ser relacionada con el total de LDC a desa- 
rrollar y con el esfuerzo de desarrollo necesario. 


La tabla siguiente [JON98] proporciona estimacio- 
nes informales del número medio de líneas de código 
que se requiere para construir un punto de función en 
varios lenguajes de programación: 


Si conoces el número 
de LDC's, ¿es posible estimar 
el numero de puntos de función? 


3 Es importante destacar que la «la individualización de compo- 
nentes importantes» se puede interpretar de muchas maneras. 
Algunos ingenieros del software que trabajan en un entorno de 
desarrollo orientado a objetos (Cuarta Parte) utilizan ciertas cla- 
sesu objetos como métrica dominante del tamaño. Una organi- 
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El punto de función (y sus extensiones), como la 
medida LDC, es controvertido. Los partidarios afirman 
que PF es independiente del lenguaje de programación, 
lo cual es ideal para aplicaciones que utilizan lenguajes 
convencionales y no procedimentales; esto se basa en 
los datos que probablemente se conocen al principio de 
la evolución de un proyecto, y así el PFes más atracti- 
vo como enfoque de estimación. 


Sentencias 
semánticas 


Pasos de 
proceso 


FIGURA 4.6. Cálculo de los Índices de los puntos 
de función 3D. 


Los detractores afirman que el método requiere algún 
«juego de manos» en el que el cálculo se base en datos 
subjetivos y no objetivos; y afirman que las cuentas del 
dominio de información (y otras dimensiones) pueden 
ser difíciles de recopilar después de realizado, y por últi- 
mo que el PF no tiene un significadofísico directo ——es 
simplemente un número—. 


Lenguaje de programación LDC/PF (media) 
Ensamblador 320 
C 128 
COBOL 106 
FORTRAN 106 
Pascal 90 
C++ 64 
Ada95 53 
Visual Basic 32 
Smalltalk 22 
Powerbuilder (generador de código) 16 
sQL 12 


Ronseo 


Utilice el repaso de los datos de un modo juicioso. 
Es bastante mejor calcular los PF utilizando los métodos 
utilizadas anteriormente. 


zación de mantenimiento podría observar el tamaño de los pro- 
yectos en relación con los pedidos de cambio de ingeniería (Capi- 
tulo 9). Una organización de sistemas de información podría 
observar el número de procesos de negocio a los que impacta una 
aplicación. 
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Una revisión de los datos anteriores indica que una 
LDC de C++ proporciona aproximadamente 1,6 veces 
la «funcionalidad» (de media) que una LDC de FOR- 
TRAN. Además, una LDC de Visual Basic proporcio- 
na 3 veces la funcionalidad de una LDC de un lenguaje 
de programación convencional. En [JON98] se presen- 
tan datos más precisos sobre las relaciones entre los PF 
y las LDC, que pueden ser usados para «repasar» pro- 
gramas existentes, determinando sus medidas en PF (por 
ejemplo, para calcular el número de puntos de función 
cuando se conoce la cantidad de LDC entregada). 

Las medidas LDC y PF se utilizan a menudo para 
extraer métricas de productividad. Esta invariabilidad 
conduce al debate sobre el uso de tales datos. Se debe 
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comparar la relación LDC/personas-mes (6 PF/perso- 
nas-mes) de un grupo con los datos similares de otro 
grupo? ¿Deben los gestores evaluar el rendimiento de 
las personas usando estas métricas? La respuesta a estas 
preguntas es un rotundo «No». La razón para esta res- 
puesta es que hay muchos factores que influyen en la 
productividad, haciendo que la comparación de «man- 
zanas y naranjas» sea mal interpretada con facilidad. 

Se han encontrado los puntos de función y las LDC 
basadas en métricas para ser predicciones relativamen- 
te exactas del esfuerzo y coste del desarrollo del soft- 
ware. Sin embargo, para utilizar LDC y PF en las 
técnicas de estimación (capítulo 5), debe establecerse 
una línea base de información histórica. 


El objetivo primordial de la ingeniería del softwarees pro- 
ducir un sistema, aplicación o producto de alta calidad. 
Para lograr este objetivo, los ingenieros del software deben 
aplicar métodos efectivosjunto con herramientas moder- 
nas dentro del contexto de un proceso maduro de desa- 
mollo de software. Además, un buen ingeniero del software 
(y buenos gestores de la ingeniería del software) deben 
medir si la alta calidad se va a llevar a cabo. 

La calidad de un sistema, aplicación o producto es 
tan bueno como los requisitos que describen el proble- 
ma, el diseño que modcla la solución, el código que con- 
duce a un programa ejecutable, y las pruebas que 
ejercitan el software para detectar errores. Un buen inge- 
niero del software utiliza mediciones que evalúan la 
calidad del análisis y los modelos de diseño, el código 
fuente, y los casos de prueba que se han creado al apli- 
car la ingeniería del software. Para lograr esta evalua- 
ción de la calidad en tiempo real, el ingeniero debe 
utilizar medidas técnicas (Capítulos 19 y 24) que eva- 
lúan la calidad con objetividad, no con subjetividad. 


Referencia Web 
Se puede encontrar una excelentefuente de información 


sobre la calidad del software y ternos relacionados 
(incluyendo métricas) en: www.qualityworld.com 


El gestor de proyectos también debe evaluar la cali- 
dad objetivamente, y no subjetivamente. A medida que 
el proyecto progresa el gestor del proyecto también debe 
evaluar la calidad. Las métricas privadas recopiladas por 
ingenieros del software particulares se asimilan para pro- 
porcionar resultados en los proyectos. Aunque se pueden 
recopilar muchas medidas de calidad, el primer objetivo 
en el proyecto es medir errores y defectos. Las métricas 
que provienen de estas medidas proporcionan una indi- 
cación de la efectividad de las actividades de control y 
dela garantía de calidad en grupos o en particulares. 
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Referencia cruzada 


En el capitulo 8 se presento un estudio detallada sobre 
los actividades de garantía de calidad del software, 


4.5.1. Visión general de los factores que afectan 
a la calidad 


Hace 25 años, McCall y Cavano [MCC78] definieron un 
juego de factores de calidad como los primeros pasos hacia 
el desarrollode métricas de la calidad del software. Estos 
factores evalúan el software desde tres puntos de vista dis- 
tintos: (1) operación del producto (utilizándolo), (2) revi- 
sión del producto (cambiándolo), y (3) transición del 
producto (modificándolo para que funcione en un entor- 
no diferente, por ejemplo, «portándolo»).Los autores, en 
su trabajo, describen la relación entre estos factores de 
calidad (lo que llaman un «marco de trabajo») y otros 
aspectos del proceso de ingeniería del software: 

En primer lugar, el marco de trabajo proporciona un meca- 
nismo para que el gestor del proyecto identifiquelo que consi- 
dera importante. Estas cualidades son atributos del software, 
además de su corrección y rendimiento funcional, que tiene 
implicacionesen el ciclo de vida. En otros factores, como son 
facilidad de mantenimiento y portabilidad, se ha demostrado 
que tienen un impacto significativoen el coste del ciclo de vida... 


En segundo lugar, el marco de trabajo proporciona un medio 
de evaluar cuantitativamente lo bien que va progresando el desa- 
rrollo en relación con los objetivos de calidad establecidos... 


En tercer lugar, el marco de trabajo proporciona más inte- 
racción del personal de QA (garantía de calidad) en el esfuer- 
zo de desarrollo... 


Por Último,. .. el personal de garantía de calidad puede uti- 
lizar indicaciones de calidad pobre para ayudar a identificar 
estándares [mejores] a enfrentar en el futuro. 


Un estudio detallado del marco de trabajo de McCall 
y Cavano, así como otros factores de calidad, se pre- 
sentan en el Capítulo 19. Es interesante destacar que 
casi todos los aspectos del cálculo han sufrido cambios 
radicales con el paso de los años desde que McCall y 
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Cavano hicieron su trabajo, con gran influencia,en 1978. 
Pero los atributos que proporcionan una indicación de 
la calidad del software siguen siendo los mismos. 


a 
al 


CLAVE 


Sorprendentemente, losfactores que definían lo calidad 
del software en el año 1970 san los mismos factores 
que continúan definiendo la calidad del software 

en la primera década de este siglo. 


¿Qué significa esto? Si una organización de software 
adopta un juego de factores de calidad como una «lista 
de comprobación» para evaluar la calidad del softwa- 
re, es probable que el softwareconstruido hoy siga exhi- 
biendo la calidad dentro de las primeras décadas de este 
siglo. Incluso, cuando las arquitecturas de cálculo sufren 
cambios radicales (como seguramente ocurrirá), el soft- 
ware que exhibe alta calidad en operación, transición y 
revisión continuará sirviendo también a sus usuarios. 


4.5.2. Medida de la calidad 


Aunque hay muchas medidas de la calidad de softwa- 
re, la corrección, facilidad de mantenimiento, integri- 
dad, yfacilidad de uso proporcionan indicadores Útiles 
para el equipo del proyecto. Gilb [GIL88] ha sugerido 
definiciones y medidas para cada uno de ellos. 


Corrección. Un programa debe operar correcta- 
mente O proporcionará poco valor a sus usuarios. La 
corrección es el grado en el que el software lleva a 
cabo su función requerida. La medida más común de 
corrección es defectos por KLDC, en donde un 
defecto se define como una falta verificada de con- 
formidad con los requisitos. 


Facilidad de mantenimiento. El mantenimiento 
del software cuenta con más esfuerzo que cualquier 
otra actividad de ingeniería del software. La facili- 
dad de mantenimiento es la facilidad con la que se 
puede corregir un programa si se encuentra un error, 
se puede adaptar si su entorno cambia, o mejorar si 
el cliente desea un cambio de requisitos. No hay 
forma de medir directamente la facilidad de mante- 
nimiento; por consiguiente, se deben utilizar medi- 
das indirectas. Una simple métrica orientada al 
tiempo es el tiempo medio de cambio (TMC), es decir 
el tiempo que se tarda en analizar la petición de cam- 
bio, en diseñar una modificación adecuada, en imple- 
mentar el cambio, en probarlo y en distribuir el 
cambio a todos los usuarios. Como media, los pro- 
gramas que se pueden mantener tendrán un TMC 
más bajo (para tipos equivalentes de cambios) que 
los programas que no son más fáciles de mantener. 

Hitachi [TAJ81] ha utilizado una métrica orien- 
tada al coste para la capacidad de mantenimiento lla- 
mada «desperdicios» —el coste en corregir defectos 
encontrados después de haber distribuidoel software 
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a sus usuarios finales —. Cuando la proporción de 
desperdicios en el coste global del proyecto (para 
muchos proyectos) se representa como una función 
del tiempo, el gestor puede determinar si la facilidad 
total del software producido por una organización de 
desarrollo está mejorando. Se pueden emprender 
acciones a partir de las conclusiones obtenidas de 
esa información. 


Integridad. En esta época de «hackers» y «fire- 
walls», la integridad del software ha llegado a tener 
mucha importancia. Este atributo mide la capacidad 
de un sistema para resistir ataques (tanto accidentales 
como intencionados) contra su seguridad. El ataque 
se puede realizar en cualquiera de los tres componentes 
del software: programas, datos y documentos. 


Para medir la integridad, se tienen que definir 
dos atributos adicionales: amenaza y seguridad. 
Amenaza es la probabilidad (que se puede estimar 
o deducir de la evidencia empírica) de que un ata- 
que de un tipo determinado ocurra en un tiempo 
determinado. La seguridad es la probabilidad (que 
se puede estimar o deducir de la evidencia empí- 
rica) de que se pueda repeler el ataque de un tipo 
determinado. La integridad del sistema se puede 
definir como: 


integridad = 2 [(1 — amenaza) X (1 — seguridad)] 


donde se suman la amenaza y la seguridad para cada 
tipo de ataque. 


Facilidad de uso. El calificativo«amigable con el 
usuario» se ha convertidoen omnipresenteen las dis- 
cusiones sobre productos de software. Si un programa 
no es «amigable con el usuario», frecuentementeestá 
abocado al fracaso, incluso aunque las funciones que 
realice sean valiosas. La facilidad de uso es un intento 
de cuantificar«lo amigable que puede ser con el usua- 
rio» y se puede medir en función de cuatro caracte- 
rísticas: (1) habilidad intelectual y/o física requerida 
para aprender el sistema; (2)el tiemporequerido para 
llegar a ser moderadamenteeficiente en el uso del sis- 
tema; (3) aumento neto en productividad (sobre el 
enfoque que el sistema reemplaza) medida cuando 
alguien utiliza el sistema moderadamente y eficiente- 
mente; y (4) valoración subjetiva (a veces obtenida 
mediante un cuestionario) de la disposición de los 
usuarios hacia el sistema. En el Capítulo 15 se estu- 
dia más detalladamente este aspecto. 


Los cuatro factores anteriores son sólo un ejemplo 
de todos los que se han propuesto como medidas de la 
calidad del software. El Capítulo 19considera este tema 
con más detalle. 


4.5.3. Eficacia de la Eliminación de Defectos 


Una métrica de la calidad que proporciona beneficios 
tanto a nivel del proyecto como del proceso, es la efi- 
cacia de la eliminación de defectos (EED).En esen- 
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cia, EED es una medida de la habilidad de filtrar las 
actividades de la garantía de calidad y de control al 
aplicarse a todas las actividades del marco de trabajo 
del proceso. 

Cuando un proyecto se toma en consideración glo- 
balmente, EED se define de la forma siguiente: 


EED=E/(E+D) (4.4) 


donde E es el número de errores encontrados antes de 
la entrega del software al usuario final y D es el núme- 
ro de defectos encontrados después de la entrega. 


¿Qué es la eficiencia 
de eliminación de defectos? 


El valor ideal de EED es 1. Esto es, no se han encon- 
trado defectos en el software. De forma realista, D será 
mayor que cero, pero el valor de EED todavía se pue- 
de aproximar a 1. Cuando E aumenta (para un valor de 
D dado), el valor total de EED empieza a aproximarse 
a 1. De hecho, a medida que E aumenta, es probable 
que el valor final de D disminuya (los errores se filtran 
antes de que se conviertan en defectos). Si se utilizan 
como una métrica que proporciona un indicador de la 
habilidad de filtrar las actividades de la garantía de la 
calidad y del control, EED anima a que el equipo del 


La mayoría de los desarrolladores de software todavía 
no miden, y por desgracia, la mayoría no desean ni 
comenzar. Como se ha señalado en este capítulo, el pro- 
blema es cultural. En un intento por recopilar medidas 
en donde no se haya recopilado nada anteriormente, a 
menudo se opone resistencia: «¿Por qué necesitamos 
hacer esto?», se pregunta un gestor de proyectos ago- 
biado. «No entiendo por qué», se queja un profesional 
saturado de trabajo. 

En esta sección, consideraremos algunos argumen- 
tos para las métricas del software y presentaremos un 
enfoque para instituir un programa de métricas dentro 
de una organización de ingeniería del software. Pero 
antes de empezar, consideremos algunas palabras de 
cordura sugeridas por Grady y Caswell [GRA87]: 


Algunas de las cosas que describimos aquí parecen bastan- 
te fáciles. Realmente, sin embargo, establecer un programa de 
métricas del software con éxito es un trabajo duro. Cuando 
decimos esto debes esperar al menos tres años antes de que 
estén disponibles las tendencias organizativas, lo que puede 
darte alguna idea del ámbito de tal esfuerzo. 


La advertencia sugerida por los autores se conside- 
ra de un gran valor, pero los beneficios de la medición 
son tan convincentes que obligan a realizar este duro 
trabajo. 


se 
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proyecto de software instituya técnicas para encontrar 
todos los errores posibles antes de su entrega. 

EED también se puede utilizar dentro del proyecto 
para evaluar la habilidad de un equipo en encontrar erro- 
res antes de que pasen a la siguiente actividad estructu- 
ral o tarea de ingeniería del software. Por ejemplo, la tarea 
del análisis de los requisitos produce un modelo de aná- 
lisis que se puede revisar para encontrar y corregir erro- 
res. Esos erroresque no se encuentren durante la revisión 
del modelo de análisis se pasan a la tarea de diseño (en 
donde se pueden encontrar O no). Cuando se utilizan en 
este contexto, EED se vuelve a definir como: 


EED, =E; /(E; +E; ,1) (4.5) 


en donde E, es el número de errores encontrado duran- 
te la actividad de ingeniería del software ¡ y E; , ¡ es el 
número de errores encontrado durante la actividad de 
ingeniería del software ¡ + / que se puede seguir para 
llegar a errores que no se detectaron en la actividad de 


la ingeniería del software i 


Cons 


Utilice£ED como una medido de la eficiencia 

de sus primeros actividades de SQA. SiEED es bajo 
durante el análisis y diseño, emplee algún tiempo 
mejorando la forma de conducir los revisiones técnicos 
formales. 


LAS MÉTRICAS DENTRO DEL PROCESO DE INGENIERÍA 


4.6.1. Argumentos para las Métricas del Software 


¿Por qué es tan importante medir el proceso de inge- 
niería del software y el producto (software) que produ- 
ce? La respuesta es relativamente obvia. Si no se mide, 
no hay una forma real de determinar si se está mejo- 
rando. Y si no se está mejorando, se está perdido. 


los números» en muchos 
os vidas... Estos NÚmeros nos 
ayudan o dirigir nuestros 


La gestión de alto nivel puede establecer objetivos 
significativos de mejora del proceso de ingeniería del 
software solicitando y evaluando las medidas de pro- 
ductividad y de calidad. En el Capítulo1 se señaló que 
el software es un aspecto de gestión estratégico para 
muchas compañías. Si el proceso por el que se desa- 
rrolla puede ser mejorado, se producirá un impacto direc- 
to en lo sustancial. Pero para establecer objetivos de 
mejora, se debe comprender el estado actual de desa- 
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rrollo del software. Por lo tanto la medición se utiliza 
para establecer una línea base del proceso desde donde 
se pueden evaluar las mejoras. 

Los rigores del trabajo diario de un proyecto del soft- 
ware no dejan mucho tiempo para pensar en estrategias. 
Los gestores de proyecto de software están más preo- 
cupados por aspectos mundanos (aunque igualmente 
importantes): desarrollo de estimaciones significativas 
del proyecto; producción de sistemas de alta calidad y 
terminar el producto a tiempo. Mediante el uso de medi- 
ción para establecer una línea base del proyecto, cada 
uno de estos asuntos se hace más fácil de manejar. Ya 
hemos apuntado que la línea base sirve como base para 
la estimación. Además, la recopilación de métricas de 
calidad permite a una organización «sintonizar» su pro- 
ceso de ingeniería del software para eliminar las causas 
«poco vitales» de los defectos que tienen el mayor 
impacto en el desarrollo del software”. 

Técnicamente (en el fondo), las métricas del soft- 
ware, cuando se aplican al producto, proporcionan bene- 
ficios inmediatos. Cuando se ha terminado el diseño del 
software, la mayoría de los que desarrollan pueden estar 
ansiosos por obtener respuestas a preguntas como: 

+ ¿Qué requisitos del usuario son más susceptibles al 
cambio? 
+. ¿Qué módulos del sistema son más propensos a error? 


. ¿Cómo se debe planificar la prueba para cada 
módulo? 

+ ¿Cuántos errores (de tipos concretos) puede esperar 
cuando comience la prueba? 


Se pueden encontrar respuestas a esas preguntas si 
se han recopilado métricas y se han usado como guía 
técnica. En posteriores capítulos examinaremos cómo 
se hace esto. 


4.6.2. Establecimiento de una Línea Base 


Estableciendouna línea base de métricas se pueden obte- 
ner beneficios a nivel de proceso, proyecto y producto (téc- 
nico). Sin embargola información reunida no necesita ser 
fundamentalmente diferente. Las mismas métricas pueden 
servir varias veces. Las líneas base de métricas constan de 
datos recogidos de proyectos de software desarrollados 
anteriormente y pueden ser tan simples como la tabla mos- 
trada en la figura 4.4o tan complejas como una gran base 
de datos que contenga docenas de medidas de proyectos 
y las métricas derivadas de ellos. 

Para ser una ayuda efectiva en la mejora del proceso 
y/o en la estimación del esfuerzo y del coste, los datos de 
línea base deben tener los siguientes atributos: (1) los datos 
deben serrazonablementeexactos —se deben evitar «con- 
jeturas» sobre proyectos pasados —, (2) los datos deben 
reunirse del mayor número de proyectos que sea posible; 


? Estas ideas se han formalizado en un enfoque denominado garan- 
tía estadística de calidad del software y se estudian en detalle en el 
Capítulo 8. 
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(3)las medidas deben ser consistentes, por ejemplo, una 
línea de código debe interpretarse consistentemente en 
todos los proyectos para los que se han reunido los datos: 
(4)las aplicacionesdeben ser semejantes para trabajar en 
la estimación —tienepoco sentido utilizar una línea base 
obtenida en un trabajo de sistemas de información batch 
para estimar una aplicación empotrada de tiempo real — 


4.6.3, Colecciónde métricas,cómputoy evaluación 


El proceso que establece una línea base se muestra en la 
Figura 4.7. Idealmente, los datos necesarios para estable- 
cer una línea base se han ido recopilando a medida que se 
ha ido progresando. Por desgracia, este no es el caso. Por 
consiguiente, la recopilación de datos requiere una inves- 
tigación histórica de los proyectos anteriores para recons- 
truir los datos requeridos. Una vez que se han recopilado 
medidas (incuestionablementeel paso más difícil), el cál- 
culo de métricas es posible. Dependiendo de la amplitud 
de las medidas recopiladas, las métricas pueden abarcar 
una gran gama de métricas LDC y PF, asícomo métricas 
de la calidad y orientadas al proyecto. Finalmente, las 
métricas se deben evaluar y aplicar durante la estimación, 
el trabajo técnico, el control de proyectos y la mejora del 
proceso. La evaluación de métricas se centra en las razo- 
nes de los resultados obtenidos, y produce un grupo de 
indicadores que guían el proyecto o el proceso. 


%, 
a 
(-) 
CLAVE 
los datos de las métricas de línea base deberían 


recogerse de una gran muestra representativa 
de proyectos de software del pasado. 


Proceso 
de ingeniería 
de software 


Proyecto 
del software 


Recopilación 
de datos 


Medidas 


Cálculo 


de métricas H Métricas 


Evaluación 


de métricas Bindicadores 


FIGURA 4.7. Proceso de recopilación de métricas 
del software. 
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Uno de los problemas al que se han enfrentado los tra- 
bajadores de las métricas durante las dos últimas déca- 
das es la de desarrollar métricas que fueran útiles para 
el diseñador de software. Ha sido toda una historia de 
utilización de la métrica dentro de los entornos indus- 
triales basada en el simple criterio de lo que era facili- 
tar la medida, más que emplear cualquier criterio 
relacionado con la utilidad. El panorama de la Última 
mitad de los años 80 y la primera mitad de la década de 
los 90, constató el hecho de que mientras había sido 
desarrollado mucho trabajo en la validación de la métri- 
ca y en el esclarecimiento de los principios teóricos 
detrás de ella, muy poco había sido hecho para dotar al 
diseñador de software con herramientas para la selec- 
ción o construcción de métricas. 

El objetivo de esta sección es describir OPM, que es 
casi con certeza el método de desarrollo de métrica más 
ampliamente aplicado y mejor conocido y que ha sido desa- 
rrollado por Victor Basili y sus colaboradores de la Uni- 
versidad de Maryland. Basili y sus colaboradores tenían 
ya una larga historia de validación de métricas en la déca- 
da de los 80 y el método OPM (objetivo, pregunta y métri- 
ca) surgió de un trabajo que fue desarrollado dentro de un 
laboratorio de ingeniería del software esponsorizado por 
la Agencia Americana del Espacio, NASA. 

Basili establecía que para que una organización tuvie- 
ra un programa de medida exacto era necesario que 
tuviera constancia de tres componentes: 


1. Un proceso donde pudieran articularse metas u obje- 

tivos para sus proyectos. 

2. Un proceso donde estas metas pudieran ser traducidas 
a los datos del proyecto que exactamente reflejasen 

dichas metas u objetivos en términos de software. 

Un proceso que interpretara los datos del proyecto 

con el fin de entender los objetivos. 


Un ejemplo de un objetivo típico que bien podría ser 
adoptado por una empresa es que la cantidad de trabajo 
de revisión sobre un diseño de sistema debido a pro- 
blemas que fueran descubiertos por los programadores 
se redujera al 80 por ciento. 

A partir de este ejemplo de objetivo emerge un cier- 
to número de preguntas típicas cuya contestación podría 
ser necesaria para clarificar los objetivos y por consi- 
guiente el desarrollo de una métrica. Un conjunto de 
ejemplos de estas preguntas, se exponen a continuación: 
» ¿Cómo realizar la cuantificación de los trabajos de 

revisión? 

» ¿Debería ser tenido en cuenta el tamaño del producto 
en el cálculo de la disminución de trabajos de revi- 
sión o revisiones? 

*« Debería ser tenido en cuenta el incremento de mano 
de obra de programación requerida para validaciones 
suplementarias y trabajos de rediseño en comparación 
con el proceso actual de validar un diseño corriente. 
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Una vez que estas cuestiones se hayan establecido, 
entonces es cuando puede ser desarrollada una métrica 
que pueda ayudar a que se cumpla el objetivo planteado 
que naturalmente emergerá a partir de estas cuestiones. 

La importancia de OPM proviene no solamente del 
hecho de que es uno de los primeros intentos de desa- 
rrollar un conjunto de medidas adecuado que pueda ser 
aplicado al software, sino también al hecho de que está 
relacionado con el paradigma de mejora de procesos 
que ha sido discutido previamente. Basili ha desarro- 
llado un paradigma de mejora de calidad dentro del cual 
el método OPM puede encajarse perfectamente. El para- 
digma comprende tres etapas: 
+. Un proceso de llevar a cabo una auditoría de un pro- 

yecto y su entorno estableciendo metas u objetivos 
de calidad para el proyecto y seleccionando herra- 
mientas adecuadas y métodos y tecnologías de ges- 
tión para que dichos objetivos de calidad tengan una 
oportunidad de cumplirse. 

.« Un proceso de ejecutar un proyecto y chequear los 
datos relacionadoscon esas metas u objetivos de cali- 
dad. Este proceso es llevado a cabo en conjunción 
con otro proceso paralelo de actuación sobre los pro- 
pios datos cuando se vea que el proyecto corre peli- 
gro de no cumplir con los objetivos de calidad. 

+ Un proceso para el análisis de los datos del segundo 
paso, con el fin de poder hacer sugerencias para una 
mayor mejora. Este proceso implicaría el analizar 
los problemas ya en la etapa de recolección de datos, 
problemas en la implementación de las directivas de 
calidad y problemas en la interpretación de los datos. 


Basili [BAS96) ha proporcionado una serie de plan- 
tillas que son útiles para los desarrolládores que deseen 
utilizar el método OPM para desarrollar métricas rea- 
listas sobre sus proyectos. Los objetivos de OPM pue- 
den articularse por medio de tres plantillas que cubren 
el propósito, la perspectiva y el entorno. 

La plantilla o esquema de cálculo denominada de 
propósito se utiliza para articular o comparar lo que está 
siendo analizado y el propósito de dicha parte del pro- 
yecto. Por ejemplo, un diseñador puede desear analizar 
la efectividad de las revisiones de diseño con el propó- 
sito de mejorar la tasa de eliminación de errores de dicho 
proceso o el propio diseñador puede desear analizar las 
normas utilizadas por su empresa con el objetivo de 
reducir la cantidad de mano de obra utilizada durante 
el mantenimiento. Una segunda plantilla está relacio- 
nada con la perspectiva. Esta plantilla pone su atención 
en los factores que son importantes dentro del propio 
proceso o producto que está siendo evaluado. Ejemplos 
típicos de esto incluyen los factores de calidad de la 
mantenibilidad, chequeo, uso y otros factores tales como 
el coste y la corrección. Esta plantilla se fundamenta en 
la perspectiva del propio proceso al que se dirige. 
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Hay varios enfoques que pueden hacerse sobre el pro- 
ceso de desarrollo de software - e 1 del cliente y el del 
diseñador son los dos más típicos — y la elección de una 
u otra perspectiva tiene un efecto muy grande sobre los 
análisis que se llevan a cabo. Por ejemplo, si un cierto 
proceso como una revisión de requisitos está siendo ana- 
lizadacon respecto al coste, la perspectiva del diseñador, 
es la del que desea reducir el coste del proceso en térmi- 
nos de hacerlo más eficiente en cuanto a la detección de 
errores; sin embargo, si después examinamos el mismo 
propósito pero desde el punto de vista del cliente, con- 
cretamente sobre si su personal puede emplear o no una 
gran cantidad de tiempo en dichas revisiones, entonces 
la perspectiva podría involucrar el plantearse un uso más 
eficiente de dicho tiempo empleado en las revisiones. 
Ambas perspectivas son válidas —= veces se solapan y 
a veces son antitéticas — existe, por ejemplo, una nece- 
sidad natural en el diseñador de maximizar el beneficio 
a la vez que el objetivo del cliente es la corrección máxi- 
ma del producto y la entrega dentro del plazo. Un punto 
importante a recalcares que del examen de la perspecti- 
va del producto, el desarrolladorestá en una mejor posi- 
ción para evaluar un proceso de software y un producto 
de software y también la mejora de los mismos. 

Una tercera plantilla implica el entorno. Este es el con- 
texto dentro del cual el método OPM se aplicae implica 
el examen del personal, la propia empresa y los entornos 
derecursosen los que el análisis se está llevando a cabo. 
Factores típicos de entorno incluyen, por ejemplo, el tipo 
de sistema informático que está siendo usado, las habili- 
dades del personal implicado en el proyecto, el modelo 
de ciclo de vida adoptado para tal caso, la cantidad de 
recursos adiestrados disponibles y el área de aplicación. 

Una vez que tanto el propósito como la perspectiva 
y el entorno de un objetivo han sido bien especificados, 
el proceso de planteamiento de cuestiones y el desarro- 
llo de una métrica O valoración puede comenzar. Antes 
de examinar este proceso, merece la pena dar algunos 
ejemplos de objetivos empleados en los términos plan- 
teados. El primero se describe a continuación: 

El objetivo es analizar los medios por los que revisamos 
el código de programación con el propósito de evaluar la 
efectividad en la detección de errores desde el punto de vis- 
ta del gestor del proyecto de software dentro de los proyec- 


tos que suministran programas críticos bajo el punto de vista 
de la seguridad. 


En el ejemplo planteado, el propósito es la evalua- 
ción, la perspectiva es la eliminación de defectos bajo 
el punto de vista del gestor de proyectos dentro del 
entorno de aplicaciones en los que la seguridad es un 
aspecto crítico. Otro ejemplo es: 


Nosotros deseamos examinar la efectividad de las nor- 
mas de programación que usamos para el lenguaje de pro- 
gramación C++, con el fin de determinar si son efectivos en 
la producción de software, que pueda ser reutilizado dentro 
de otros proyectos. En particular, estamos interesados en lo 
que se necesita con el fin de organizarefectivamente un depar- 
tamento nuevo encargado de el mantenimiento de una biblio- 
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teca de software reutilizable. En este estudio se da el soft- 
ware de nuestra área de aplicación principal; que es la de 
control de inventarios. 


Aquí, el propósito es la mejora de un estándar de pro- 
gramación; la perspectiva es la de la reutilización bajo 
el punto de vista del personal encargado de la adminis- 
tración de una biblioteca de software reutilizable, y el 
entorno son todos aquellos proyectos que impliquen 
funciones de control de inventarios. 

Otro ejemplo adicional es el siguiente: 

Deseamos examinar el efecto de utilizar un constructor de 
interfaces gráficas, sobre la mejora de las interfaces hombre- 
máquina, que producimos para nuestros sistemas de adminis- 
tración. En particular, deseamos examinar cómo puede esto 
afectara la facilidadde manejo de estas interfaces por parte del 
usuario. Un foco de atención principai es cómo percibirán los 
usuarios de estos sistemas que dichas interfaceshan cambiado. 

Aquí, el propósito es analizar una herramienta-con 
el objetivo de determinar una mejora con respecto a la 
facilidad de uso, bajo el punto de vista del usuario den- 
tro del contexto de los sistemas administrativos. Un 
ejemplo final es el siguiente: 

Nuestro objetivo es examinar el proceso de chequeo de 
módulos de código de forma que podamos utilizar los resulta- 
dos de las comprobaciones con el fin de predecir el número de 
defectos de código en comprobaciones futuras. La perspecti- 
va que deseamos tener surge de una preocupación sobreel exce- 
sode errores que se han cometido y queno han sido detectados 
hasta el chequeo del sistema. Deseamos ver qué factores son 
importantes que permitan que un programador tome decisio- 
nes sobre si un módulo está disponible para ser entregado a los 
probadores del sistema, o por el contrario requiere una com- 
probación adicional. Deseamos concentramosen nuestro mode- 
lo de ciclo de vida actual con programadores que utilizan el 
lenguaje de programación FORTRAN. 


Aquí, el objetivo es la predicción, el análisis de un 
proceso —el de chequeo de código — la perspectiva es 
la de reducción de costes a través de una reducción del 
número de errores residuales, que se deslizan dentro del 
propio chequeo del sistema. La perspectiva es desde el 
punto de vista del programador y el entorno el de los 
proyectos convencionales que utilizan el lenguaje de 
programación FORTRAN. 

La plantilla propósito se utiliza para definir lo que 
está siendo estudiado: podría ser un proceso, un pro- 
ducto, un estándar o un procedimiento. La plantilla tam- 
bién define lo que se va a hacer, y la razón de hacerlo. 
La perspectiva tiene el objetivo de asegurar que los obje- 
tivos no son demasiado ambiciosos: al final del día el 
método OPM requerirá la realización de medidas y estas 
medidas y los datos estadísticos asociados serán sólo 
efectivos cuanto más grande sea el número de factores 
dentro de un nivel razonable. La plantilla del entorno 
tiene una función similar: reduce el factor de espacio y 
permite que sean hechas comparaciones estadísticas 
efectivas entre procesos y productos. 

Con el fin de terminar esta sección es provechoso 
analizar el método OPM en acción sobre un pequeño 
ejemplo, con el siguiente objetivo de proceso: 
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Analícese el proceso de confección de prototipos con el pro- 
pósito de evaluar desde el punto de vista del desarrollador, el 
número de requisitos que se rechazan por el cliente en una últi- 
ma etapa del proyecto. 


Nosotros asumiremos un modelo desechable de con- 
fección de prototipos en el que se use una tecnología 
como la de un lenguaje típico de cuarta generación para 
desarrollar una versión rápida de un sistema que, cuan- 
do el cliente lo ha aceptado, se implemente de forma 
convencional con la eliminación del propio prototipo. 
Esto plantea un cierto número de preguntas que enton- 
ces pueden ser procesadas con el fin de evaluar el pro- 
ceso de confección de prototipos desechables: 

+ ¿Qué medida tomaríamos con los requerimientos que 
se hayan cambiado durante la parte convencional del 
proyecto? 

+ ¿Se deben ponderar todos los requisitos de forma 
igualitaria o son algunos más complejos que otros? 

+ ¿Qué tipos de cambios en los requisitos debemos con- 
siderar? Después de todo, algunos de ellos serán debi- 
dos a imperfecciones en el proceso de confección de 
prototipos mientras que otros podrían tener que ver 
con factores extraños que pueden ser debidos a cam- 
bios en las propias circunstancias del cliente. 


Con el fin de aplicar el método OPM, necesitamos 
un modelo del proceso que esté llevándose a cabo y un 
modelo de la perspectiva de calidad: el número de cam- 
bios en los requisitos que son exigidos por el cliente no 
provienen generalmente de cambios en sus propias cir- 
cunstancias. 

Supongamos que el modelo para el proceso de con- 
fección de prototipos desechables es: 

1. Especificar los requisitos. 

2. Valorar cada requisito en importancia según térmi- 
nos del cliente. 

Valorar cada requisito en términos de la compleji- 
dad de su descripción. 

Planificar una serie de reuniones de revisión en las que 
se presente a través de un prototipo una cierta selec- 
ción de requisitos donde el gestor del proyecto tome 
una decisión sobre en qué se basa la selección de una 
presentación de, por ejemplo, dos horas de duración. 


3. 


> 


Supongamos un modelo muy simple de perspectiva 
de calidad, dónde cada requisito R; esté asociado con 


Debido a que el proceso de software y el producto que 
tal proceso produce son ambos influenciados por 
muchos parámetros (por ejemplo: el nivel de habili- 
dad de los realizadores de dichos procesos, la estruc- 
tura del equipo de software, el conocimiento del 
cliente, la tecnología que va a ser implementada, las 
herramientas que serán usadas en la actividad de desa- 
rrollo), la métrica elegida para un proyecto o produc- 
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una complejidad ponderada C; .Entonces el tamaño de 
los requisitos totales será: 


n 
2R¡-C; 
¿=0 

Supongamos que una cierta proporción p de estos 
requisitos han sido puestos en cuestión emprendiéndo- 
se un chequeo de aceptación por parte del cliente, y que 
estos requisitos no han sido debidos a cambios en las 
propias circunstancias del cliente. Entonces, la métrica 

n 
e=p:*YER;¡C; 
i=0 
representa una cierta medida de la desviación de los 
requisitos desde el prototipo a lo largo del chequeo de 
aceptación. 

Este valor puede entonces ser comparado con los 
valores base de otros proyectos de confección de pro- 
totipos que tengan un entorno parecido. Si se ha obser- 
vado una cierta mejora, la siguiente etapa es intentar 
descubrir cómo se ha logrado esta mejora, por ejemplo, 
en este proyecto el cliente puede haber enviado el mis- 
mo representante para ayudar en las demostraciones del 
prototipo y por consiguiente ha conseguido una con- 
sistencia mayor que faltaba en otros proyectos, O el per- 
sonal del desarrollo que estaba implicado en el proyecto 
puede haber estado formado por analistas en lugar de 
diseñadores, y así haber constituido una más sólida rela- 
ción con el cliente. Si se observaba un incremento en la 
métrica e, entonces un análisis similar debería llevarse 
a cabo en términos de lo que constituían los factores 
desfavorables que afectaban al proyecto. 

Lo ya expuesto, entonces, ha sido un resumen esque- 
mático del proceso OPM. Un punto importante a con- 
siderar es que ya que existe un número casi infinito de 
métricas que pueden usarse para caracterizar un pro- 
ducto de software y un proceso de software existe una 
necesidad de determinar la forma de seleccionarlas, o 
dicho de otra forma, cuál de las OPM es el mejor ejem- 
plo. Una vez que esto ha sido tomado en consideración 
en una empresa, esa empresa puede entonces implicar- 
se en una actividad continua de mejora de procesos, que 
la coloque en un nivel 4 Ó 5 de la Escala de Modelos de 
Madurez de Capacidades y así distinguirla de aquellas 
otras que lleguen sólo a niveles 16 2. 


e. 
O 
O 
g 


to no será la misma que otras métricas similares selec- 
cionadas para otro proyecto. En efecto, hay a menudo 
variaciones significativas en las métricas elegidas como 
parte del proceso de software. 

Puesto que la misma métrica de procesos variará de un 
proyecto a otro proyecto, ¿cómo podemos decir si unos 
valores de métricas mejoradas (o degradadas) que ocu- 
rren como consecuencia de actividades de mejora están 
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de hecho teniendo un impacto cuantitativo real? ¿Cómo 
saber silo que nosotros estamos contemplando es una ten- 
dencia estadísticamente válida o si esta «tendencia» es 
simplementeel resultado de un ruido estadístico? ¿Cuán- 
do son significativos los cambios (ya sean positivos O 
negativos) de una métrica de software particular? 


He i paro la gestión 
todo lo que hoy 


Se dispone de una técnica gráfica para determinar si 
los cambios y la variación en los datos de la métrica son 
significativos. Esta técnica llamada gráfico de control 
y desarrollada por Walter Shewart en 1920", permite 
que los individuos o las personas interesadas en la mejo- 
ra de procesos de software determine si la dispersión 
(variabilidad) y «la localización» (media móvil) o métri- 
ca de procesos que es estable (esto es, si el proceso exhi- 
be cambios controlados o simplemente naturales) o 
inestable (esto es, si el proceso exhibe cambios fuera 
de control y las métricas no pueden usarse para prede- 
cir el rendimiento). Dos tipos diferentes de gráficos de 
control se usan en la evaluación de los datos métricos 
[ZUL99]: (1) el gráfico de control de rango móvil (Rm) 
y (2) el gráfico de control individual. 

Para ilustrar el enfoque que significa un gráfico de 
control, consideremos una organización de software que 
registre en la métrica del proceso los errores descubiertos 
por hora de revisión, E, Durante los pasados 15meses, 
la organización ha registrado el E,. para 20 pequeños 
proyectos en el mismo dominio de desarrollo de soft- 
ware general. Los valores resultantes para E, están repre- 
sentados en la figura 4.8. Si nos referimos a la figura, 
E, varía desde una tasa baja de 1.2 para el proyecto 3 a 
una tasa más alta de 5.9 para el proyecto 17. En un 
esfuerzo de mejorar la efectividad de las revisiones, la 
organización de software proporcionaba entrenamien- 
to y asesoramiento a todos los miembros del equipo del 
proyecto, comenzando con el proyecto 11, 


¿Cómo podemosestar 
seguros de que las métricas 
que hemos recopilado son 
estadísticamente validas? 


Richard Zultner proporciona una vista general del 
procedimiento que se requiere para desarrollar un grá- 
fico de control de rango móvil (Rm) para determinar la 
estabilidad del proceso [ZUL99]: 


'9 Debería tenerse en cuenta que aunque el gráfico de control fue 
desarrollado originalmente para procesos de fabricación es igual- 
mente aplicable a procesos de software. 


1. Calcular los rangos móviles: el valor absoluto de las 
diferencias sucesivas entre cada pareja de puntos de 
datos... Dibujar estos rangos móviles sobre el gráfico. 

2. Calcular la media de los rangos móviles... dibujando 
ésta («barra Rm») como la línea central del propio 
gráfico. 

3. Multiplicar la media por 3.268. Dibujar esta línea 
como el límite de control superior [LCS]. Esta línea 
supone tres veces el valor de la desviación estándar 
por encima de la media. 

Usando los datos representados en la figura 4.8y los 
distintos pasos sugeridos por Zultner como anterior- 
mente se ha descrito, desarrollamos un gráfico de con, 
trol Rm que se muestra en la Figura 4.9. El valor (medio) 
«barra Rm» para los datos de rango móvil es 1.71. El 
límite de control superior (LCS) es 5.57. 


ntor señales desde el ruido, como 
mbios en el proceso son mejoras- 


Para determinar si la dispersión de las métricas del 
proceso es estable puede preguntarse una cuestión muy 
sencilla: ¿Están los valores de rango móvil dentro del 
LCS? Para el ejemplo descrito anteriormente, la con- 
testación es «sí», Por consiguiente, la dispersión de la 
métrica es estable. 

El gráfico de control individual se desarrolla de la 
manera siguiente": 

1. Dibujar los valores de la métrica individual según se 
describe en la Figura 4.8. 

2. Calcular el valor promedio, A,, para los valores de 
la métrica. 

3. Multiplicarla media de los valores Rm (la barra Rm) 
por 2.660 y añadir el valor de A, calculado en el paso 
2. Esto da lugar a lo que se denomina límite de pro- 
ceso natural superior (LPNS). Dibujar el LPNS. 

4. Multiplicar la media de los valores Rm (la barra Rm) 
por 2.660 y restar este valor del A, calculado en el 
paso 2. Este cálculo da lugar al límite de proceso 
natural inferior (LPNZ). Dibujar el LPNI. Si el LPNI 
es menor que 0.0, no necesita ser dibujado a menos 
que la métrica que está siendo evaluada tome valo- 
res que sean menores que 0.0. 

5 Calcular la desviación estándar según la fórmula 
(LPNS -— Api3. Dibujar las líneas de la desviación 
estándar una y dos por encima y por debajo de A,. 
Si cualquiera de las líneas de desviación estándar es 
menor de 0.0, no necesita ser dibujada a menos que 
la métrica que está siendo evaluada tome valores que 
sean menores que 0.0. 


"El estudio que sigue es un resumen de los pasos sugeridos por Zult- 


ner [ZUL991. 
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FIGURA 4.8. Datos de métricas para descubrir errores 
por hora de revisión. 


Aplicando estos pasos a los datos representados en 
la Figura 4.8, se llega a un gráfico de control individual 
según se ve en la figura 4.10. 


Referencia Web 
Sé puede encontrar un Gráfico de Control Común 


que cubre el tema en alguna dimensión en: 
www.sytsma.com/tqmtools/ctichfprinciples.himl 


Zultner [ZUL99] revisa cuatro criterios, denomi- 
nados reglas de zona, que pueden usarse para evaluar 
si los cambios representados por la métrica indican 
que un proceso está bajo control o fuera de control. 
Si cualquiera de las siguientes condiciones es verda- 
dera, los datos de la métrica indican un proceso que 
está fuera de control: 


1. Un valor de la métrica individual aparece fuera del 
LPNS. 

2. Dos de cada tres valores de métricas sucesivas apa- 
recen más de dos desviaciones estándar fuera del 
valor A,. 

3. Cuatro de cada cinco valores de métricas sucesivas 
aparecen alejados más de una desviación estándar 
del valor A.. 

4. Ocho valores consecutivos de métrica aparecen todos 
situados a un lado del valor A,. 
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FIGURA 4.9. Gráfico de control de rango móvil (Rm). 


Er, Errores encontrados/ 
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FIGURA 4.10. Gráfico de control individual. 
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Puesto que todas estas condiciones fallan para los 
valores mostrados para la figura 4.10, se concluye que 
los datos de las métricas se derivan de un proceso esta- 
ble y que se pueden deducir legítimamente a partir de 
los datos recogidos en la métrica una información que 
constituye una verdadera tendencia. Si nos referimos 
a la figura 4.10, puede verse que la variabilidad de E, 
decrece a partir del proyecto 10 (esto es, después de 
un esfuerzo para mejorar la efectividad de las revisio- 
nes). Calculando el valor medio para los 10 primeros 
y los 10últimos proyectos, puede demostrarse que el 
valor medio de E, para los proyectos del 11 al 20, 
muestran un 29 por 100 de mejora en relación con la 
E, de los proyectos lal 10. Puesto que el gráfico de 
control indica que el proceso es estable, parece que los 
esfuerzos para mejorar la efectividad de la revisión 
dan sus resultados. 


La amplia mayoría de las organizaciones de desarrollo 
de software tienen menos de 20 personas dedicadas al 
software. Es poco razonable, y en la mayoría de los casos 
no es realista, esperar que organizaciones como éstas 
desarrollen programas métricos de software extensos. 
Sin embargo, si que es razonable sugerir que organiza- 
ciones de software de todos los tamaños midan y des- 
pués utilicen las métricas resultantes para ayudar a 
mejorar sus procesos de software local y la calidad y 
oportunidad de los productos que realizan. Kautz 
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[KAU99] describe un escenario típico que ocurre cuan- 
do se piensa en programas métricos para organizacio- 
nes pequeñas de software: 


Originalmente, los desarrolladoresde software acogían nues- 
tras actividadescon un alto grado de escepticismo, pero al final 
las aceptaban debido a que nosotros conseguíamos que nues- 
tras medidas fueran simples de realizar, adaptadas a cada orga- 
nización y se aseguraba que dichas medidas producían una 
información válida y útil. Al final, los programas proporcio- 
naban una base para encargarse de los clientes y para la plani- 
ficación y desarrollo de su trabajo futuro. 


www.elsolucionario.net 


INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRÁCTICO 


Consic) 


Siestás empezando a reunir métricas del software, 
recuerdaguardallas. Si te entierros con datas, fu esfuerzo 
con los métricospuede fallar. 


Lo que Kautz sugiere es una aproximación para la 
implementación de cualquier actividad relacionada con 
el proceso del software: que sea simple; adaptada a satis- 
facer las necesidades locales y que se constate que real- 
mente añada valor. En los párrafos siguientes examinamos 
cómo se relacionanestas líneas generales con las métri- 
cas utilizadas para negocios pequeños. 

«Para hacerlo fácil», es una línea de acción que 
funciona razonablemente bien en muchas actividades. 
Pero jcómo deducimos un conjunto sencillo de métri- 
cas de software que proporcionen valor, y cómo pode- 
mos estar seguros de que estas métricas sencillas 
lograran satisfacer las necesidades de una organiza- 
ción de software particular? Comenzamos sin cen- 
trarnos en la medición, pero sí en los resultados 
finales. El grupo de software es interrogado para que 
defina un objetivo simple que requiera mejora. Por 
ejemplo, «reducir el tiempo para evaluar e imple- 
mentar las peticiones de cambio». Una organización 
pequeña puede seleccionar el siguiente conjunto de 
medidas fácilmente recolectables: 

* Tiempo (horas o días) que transcurren desde el 
momento que es realizada una petición hasta que se 
complete su evaluación, £..,1y: 

» Esfuerzo (horas-persona) para desarrollar la evalua- 
ción, Weyaj 

+ Tiempo (horas o días) transcurridos desde la termi- 
nación de la evaluación a la asignación de una orden 
de cambio al personal, f.yj- 

» Esfuerzo (horas-persona) requeridas para realizar el 
cambio, W cambio 

» Tiemporequerido (horas o días) para realizar el cam- 
bio, Icambio* 

» Errores descubiertos durante el trabajo para realizar 


el cambio, E combles 


El Instituto de Ingeniería del Software (IIS) ha desarro- 
llado una guía extensa |PAR96] para establecer un pro- 
grama de medición de software dirigido hacia objetivos. 
La guía sugiere los siguientes pasos para trabajar: 


1. Identificar los objetivos del negocio. 
2. Identificar lo que se desea saber o aprender. 
3. Identificar los subobjetivos. 


4. Identificarlas entidades y atributos relativos a esos 
subobjetivos. 


5. Formalizar los objetivos de la medición. 
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. Defectos descubiertos después de que el cambio se 
haya desviado a la base del cliente, D 
¿Cómo puedo derivar 


E un conjunto «simple» 


de métricas del software? 


cambio" 


Una vez que estas medidas han sido recogidas para 
un cierto número de peticiones de cambio, es posible cal- 
cular el tiempo total transcurrido desde la petición de 
cambio hasta la implementación de dicho cambio y el 
porcentaje de tiempo consumido por el proceso de colas 
iniciales, la asignación de cambio y evaluación, y la imple- 
mentación del cambio propiamente dicho. De forma simi- 
lar, el porcentaje de esfuerzorequerido para la evaluación 
y la implementación puede también ser determinado. 
Estas métricas pueden ser evaluadas en el contexto de los 
datos de calidad, É cambio Y D cambio: LOS porcentajes pro- 
porcionan un análisis interno para buscar el lugar donde 
los procesos de petición de cambio se ralentizan y pue- 
den conducir a unos pasos de mejoras de proceso para 
reducir£,, W, tt , W.., ,y/0E. .,.. Además, 
la eficiencia deé a sample vo SS puede ser 
calculada de la siguiente manera: 


EED = E /(E 


EED puede compararse con el tiempo transcurrido y el 
esfuerzo total para determinar el impacto de las activi- 
dades de aseguramiento de la calidad sobre el tiempo y 
el esfuerzo requeridos para realizar un cambio. 

Para grupos pequeños, el coste de incorporar medi- 
das y métricas de cálculo oscila entre el 3 y el 8 por 100 
del presupuesto del proyecto durante la fase de apren- 
dizaje y después cae a menos del 1 por 100 del presu- 
puesto del proyecto una vez que la ingeniería del 
software y la gestión de proyectos se hayan familiari- 
zado con el programa de métricas [GRA99]. Estos cos- 
tes pueden representar una mejora de las inversiones 
siempre que el análisis derivado a partir de los datos de 
la métrica conduzcan a una mejora de procesos signifi- 
cativa para la organización del software. 


+D 


cambio cambio lambial 


. Identificar preguntas que puedan cuantificarse y los 
indicadores relacionados que se van a usar para 
ayudar a conseguir los objetivos de medición. 

. Identificar los elementos de datos que se van a reco- 
ger para construir los indicadoresque ayuden a res- 
ponder a las preguntas planteadas. 

8. Definir las medidas a usar y hacer que estas defi- 
niciones sean operativas. 

. Identificar las acciones que serán tomadas para 
mejorar las medidas indicadas. 


10. Preparar un plan para implementar estas medidas. 
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Se puede descargar una guía para la medición del software 
orientado a objetivos desde: www.sei.tmu.edu 


Si se quiere entrar en una discusión más profunda de 
los pasos anteriores, lo mejor es acudir directamente a 
la guía ya comentada del IIS (SED Instituto de Inge- 
niería del Softwate. Sin embargo, merece la pena repa- 
sar brevemente los puntos clave de ésta. 

Ya que el software, en primer lugar, soporta las fun- 
ciones del negocio, en segundo lugar, diferenciao clasi- 
fica los sistemas o productos basados en computadora, y 
en tercer lugar puede actuar como un producto en sí mis- 
mo, los objetivos definidos para el propio negocio pue- 
den casi siempre ser seguidos de arriba abajo hasta los 
objetivos más específicos a nivel de ingeniería de soft- 
ware. Por ejemplo, considéreseuna compañía que fabri- 
ca sistemas avanzados para la seguridad del hogar que 
tienen un contenido de software sustancial. Trabajando 
como un equipo, los ingenieros de software y los gesto- 
res del negocio, pueden desarrollaruna lista de objetivos 
del propio negocio convenientementepriorizados: 

1. Mejorar la satisfacción de nuestro cliente con nues- 
tros productos. 

2. Hacer que nuestros productos sean más fáciles de usar. 

3. Reducir el tiempo que nos lleva sacar un nuevo 
producto al mercado. 

4, Hacer que el soporte que se dé a nuestros produc- 
tos sea más fácil. 

5. Mejorar nuestro beneficio global. 


“e 
LAVE 


las métricos del software que elijas estarbn tonducidas 
por el negocio o por los objetivos técnicos que desees 
cumplir, 


La organización de software examina cada objetivode 
negocios y se pregunta: «¿Qué actividades gestionaremos 
(ejecutaremos) y qué queremos mejorar con estas activi- 
dades?»Para responder a estas preguntas el IIS recomienda 
la creación de una «lista de preguntas-entidad», en la que 
todas las cosas (entidades) dentro del proceso de softwa- 
re que sean gestionadas o estén influenciadaspor la orga- 
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nización de software sean anotadas convenientemente. 

Ejemplo de tales entidades incluye: recursos de desarro- 

llo, productos de trabajo, código fuente, casos de prueba, 

peticiones de cambio, tareas de ingeniería de software y 

planificaciones. Para cada entidad listada, el personal dedi- 

cado al software desarrollauna serie de preguntas que eva- 
lúan las características cuantitativas de la entidad (por 
ejemplo: tamaño, coste, tiempo para desarrollarlo). Las 
cuestiones derivadas como una consecuenciade la crea- 
ciónde una lista tal de preguntas-entidad, conducen a la 
derivación de un conjunto de objetivos de segundo nivel 

(subobjetivos)que se relacionan directamentecon las enti- 

dades creadas y las actividades desarrolladas como una 

parte del proceso del software. 

Considérese el cuarto objetivo apuntado antes: 
«Hacer que el soporte para nuestros productos sea más 
fácil». La siguiente lista de preguntas pueden ser deri- 
vadas a partir de este objetivo [PAR96]: 

» ¿Contienen las preguntas de cambio del cliente la 
información que nosotros requerimos para evaluar 
adecuadamente el cambio y de esa forma realizarle 
en un tiempo y formas oportunos? 

» ¿Cómo es de grande el registro de peticiones de 
cambio? 

+ ¿Es aceptablenuestro tiempo de respuesta para localizar 
errores de acuerdo a las necesidades del cliente? 

» ¿Se sigue convenientemente nuestro proceso de 
control de cambios (Capítulo 9)? 

+ ¿Se llevan a cabo los cambios de alta prioridad de 
manera oportuna y sincronizada? 


Basándose en estas cuestiones, la organización de 
software puede deducir los objetivos de segundo nivel 
(subobjetivos) siguientes: Mejorar el rendimiento del 
proceso de gestión del cambio. Las entidades de proceso 
de software y atributos que son relevantes para los 
propósitos u objetivos más específicos o de segundo 
nivel son identificados y se definen además las metas u 
objetivos de medida asociados con dichos atributos. 

El IIS [PAR96] proporciona una guía detallada para 
los pasos 6 al 10 de este enfoque de medida orienta- 
do hacia objetivos. En esencia, se aplica un proceso 
de refinamiento por pasos en el que los objetivos son 
refinados en preguntas que son a su vez refinadas de 
forma más detallada en entidades y atributos que por 
Último se analizan en un Último paso de forma más 
minuciosa a nivel de la métrica en sí. 


La medición permite que gestores y desarrolladores 
mejoren el proceso del software, ayuden en la pla- 
nificación, seguimiento y control de un proyecto de 
software, y evalúen la calidad del producto (soft- 
ware) que se produce. Las medidas de los atributos 
específicos del proceso, del proyecto y del produc- 
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to se utilizan para calcular las métricas del softwa- 
re. Estas métricas se pueden analizar para propor- 
cionar indicadores que guían acciones de gestión y 
técnicas. 

Las métricas del proceso permiten que una orga- 
nización tome una visión estratégica proporcionan- 
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do mayor profundidad de la efectividad de un proce- 
so de software. Las métricas del proyecto son tácti- 
cas. Estas permiten que un gestor de proyectos adapte 
el enfoque a flujos de trabajo del proyecto y a pro- 
yectos técnicos en tiempo real. 

Las métricas orientadas tanto al tamaño como a la 
función se utilizan en toda la industria. Las métricas 
orientadas al tamaño hacen uso de la línea de código 
como factor de normalización para otras medidas, 
como persona-mes o defectos. El punto de función 
proviene de las medidas del dominio de información 
y de una evaluación subjetiva de la complejidad del 
problema. 

Las métricas de la calidad del software, como 
métricas de productividad, se centran en el proceso, 
en el proyecto y en el producto. Desarrollando y ana- 
lizando una línea base de métricas de calidad, una 
organización puede actuar con objeto de corregir esas 


áreas de proceso del software que son la causa de los 
defectos del software. 

Las métricas tienen significado solo si han sido 
examinadas para una validez estadística. El gráfico 
de control es un método sencillo para realizar esto y 
al mismo tiempo examinar la variación y la localiza- 
ción de los resultados de las métricas. 

La medición produce cambios culturales. La reco- 
pilación de datos, el cálculo de métricas y la evaluación 
de métricas son los tres pasos que deben implementar- 
se al comenzar un programa de métricas. En general, 
un enfoque orientado a los objetivos ayuda a una orga- 
nización a centrarse en las métricas adecuadas para su 
negocio. Los ingenieros del software y sus gestores pue- 
den obtener una visión más profunda del trabajo que 
realizan y del producto que elaboran creando una línea 
base de métricas —una base de datos que contenga 
mediciones del proceso y del producto—. i 
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411. Sugiera tres medidas, tres métricas y los indicadores que 
se podrían utilizar para evaluar un automóvil. 


4.2. Sugiera tres medidas, tres métricas y los indicadores 
correspondientes que se podrían utilizar para evaluar el 
departamento de servicios de un concesionario de automó- 
viles. 


43, Describa, con sus propias palabras, la diferencia entre 
métricas del proceso y del proyecto. 


44, ¿Por qué las métricas del software deberían mantenerse 
«privadas»?Proporcione ejemplos de tres métricas que debie- 
ran ser privadas. Proporcione ejemplos de tres métricas que 
debieran ser públicas. 


45. Obtenga una copia de [HUM9S5] y escriba un resumen en 
una O dos páginas que esquematice el enfoque PSP. 


46. Grady sugiere una etiqueta para las métricas del soft- 
ware. ¿Puede añadir más reglas a las señaladas en la Sec- 
ción 4.2.1? 


4,7. Intente completar el diagrama en espina de la Figura 4.3. 
Esto es, siguiendo el enfoque utilizado para especificaciones 
«incorrectas» proporcione información análoga para «perdi- 
do, ambiguo y cambios». 


48. ¿Qué es una medida indirecta y por qué son comunes tales 
cambios en un trabajo de métricas de software? 


49. El equipo A encontró 342 errores durante el proceso de 
ingenieríadel software antes de entregarlo. El equipo B encon- 
tró 184 errores. ¿Qué medidas adicionales se tendrían que 
tomar para que los proyectos A y B determinen qué equipos 
eliminaron los errores más eficientemente? ¿Qué métricas pro- 
pondrían para ayudar a tomar determinaciones? ¿Qué datos 
históricos podrían ser útiles? 


4,10. Presente un argumento en contra de las líneas de códi- 
go como una medida de la productividad del software. ¿Se va 
a sostener su propuesta cuando se consideren docenas o cien- 
tos de proyectos? 


4.11. Calcule el valor del punto de función de un proyecto con 
las siguientes características del dominio de información: 


Número de entradas de usuario: 32 
Número de salidas de usuario: 60 
Número de peticiones de usuario: 24 


La mejora del proceso del software (MPS) ha recibido una 
significativa atención durante la pasada década. Puesto que 
la medición y las métricas del software son claves para con- 
seguir una mejora del proceso del software, muchos libros 
sobre MPS también tratan las métricas. Otras lecturas adi- 
cionales que merecen la pena incluyen: 

Burr, A., y M. Owen, Statistical Methosfor Software Qua- 
lity, Intemational Thomson Publishing, 1996. 

Florac, W. A., y A. D. Carleton, Measuring the Software 
Process: Statistical Process Control for Software Process 
Improvement, Addison-Wesley, 1999. 
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Número de archivos: 8 
Número de interfaces externos: 2 


Asuma que todos los valores de ajuste de complejidad están 
en la media. 


4.12. Calcule el valor del punto de función de un sistemaempo- 
trado con las características siguientes: 


Estructuras de datos interna: 6 
Estructuras de datos externa: 3 
Número de entradas de usuario: 12 
Número de salidas de usuario: 60 
Número de peticiones de usuario: 9 
Número de interfaces externos: 3 
Transformaciones: 36 
Transiciones: 24 


Asuma que la complejidad de las cuentas anteriores se divi- 
de de igual manera entre bajo, medio y alto. 


4.13. El software utilizado para controlar una fotocopiadora 
avanzada requiere 32.000 líneas de C y 4.200 líneas de Small- 
talk. Estime el número de puntos de función del software de 
la fotocopiadora. 


4.14. McCall y Cavano (Sección 4.5.1) definen un «marco de 
trabajo» de la calidad del software. Con la utilización de la 
información de este libro y de otros se amplían los tres «pun- 
tos de vista» importantes dentro del conjunto de factores y de 
métricas de calidad. 


4.15. Desarrolle sus propias métricas (noutilice las presenta- 
das en este capítulo) de corrección, facilidad de mantenimiento; 
integridad y facilidad de uso. Asegúrese de que se pueden tra- 
ducir en valores cuantitativos. 


4.16. ¿Es posible que los desperdicios aumenten mientras que 
disminuyen defectos/KLDC? Explíquelo. 


4.17. ¿Tiene algún sentido la medida LDC cuando se utiliza 
el lenguaje de cuarta generación? Explíquelo. 


4.18. Una organización de software tiene datos EED para 15 
proyectos durante los 2 últimos años. Los valores recogidos 
son: 0.81,0,71, 0.87, 0,54, 0.63, 0.71, 0.90, 0.82, 0.61, 0.84, 
0.73, 0.88, 0.74, 0.86, 0,83. Cree Rm y cuadros de control indi- 
viduales para determinar si estos datos se pueden utilizar para 
evaluar tendencias. 


cd 


Garmus, D., y D. Herron, Measuring the Software Pro- 
cess: A Practical Guide to Functional Measurements, Pren- 
tice-Hall, 1996. 

Kan, S. H., Metrics and Models in Software Quality Engi- 
neering, Addison-Wesley, 1995. 

Humphrey [HUMOS], Yeh (Software Process Control, 
McGraw-Hill, 1993), Hetzel [HET93] y Grady [GRA92] estu- 
dian cómo se pueden utilizar las métricas del software para pro- 
porcionar los indicadores necesarios que mejoren el proceso 
del software. Putnam y Myers (Executive Briefing: Controlling 
Software Development, IEEE Computer Society, 1996) y Pul- 
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ford y sus colegas (A Quantitative Approach to Software Mana- 
gement, Addison-Wesley, 1996)estudian las métricas del pro- 
ceso y su uso desde el punto de vista de la gestión. 

Weinberg (Quality Software Management, Volume2: First 
Order Measurement, Dorset House, 1993)presenta un mode- 
lo útil para observar proyectos de software, asegurándose el 
significado de la observación y determinando el significado 
de las decisiones tácticas y estratégicas. Garmus y Herron 
(Measuring the Software Process, Prentice-Hall, 1996) trata 
las métricas del proceso en el análisis del punto de función. 
El Software Productivity Consortium (The Software Measu- 
rement Guidebook, Thomson Computer Press, 1995) pro- 
porciona sugerencias útiles para instituir un enfoque efectivo 
de métricas. Oman y Pfleeger (Applying Software Metrics, 
TEEE Computer Society Press, 1997) han editado una exce- 
lente antología de documentos importantes sobre las métri- 
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cas del software. Park y otros [PAR96] han desarrollado una 
guía detallada que proporciona paso a paso sugerencias para 
instituir un programa de las métricas del software para la 
mejora del proceso del software. 

La hoja informativalT Metrics (Editada por Howard Rubin 
y publicada por los Servicios de Información Cutter) presen- 
ta comentarios Útiles sobre el estado de las métricas del soft- 
ware en la industria. Las revistas Cutter! T Journal y Software 
Development tienen habitualmente artículos y característi- 
cas completas dedicadas a las métricas del software. 

En Intemet están disponibles una gran variedad de fuen- 
tes de información relacionadas con temas del proceso del 
software y de las métricas del software. Se puede encontrar 
una lista actualizada con referencias a sitios (páginas) web 
que son relevantes para el proceso del Software y para las 
métricas del proyecto en http://www.pressman5.com. 
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CAPÍTULO 


PLANIFICACIÓN DE PROYECTOS 
DE SOFTWARE 


A gestión de un proyecto de software comienza con un conjunto de actividades que glo- 

balmente se denominan planificación del proyecto. Antes de que el proyecto comience, 

el gestor y el equipo de software deben realizar una estimación del trabajo a realizar, de 
los recursos necesarios y del tiempo que transcurrirá desde el comienzo hasta el final de su rea- 
lización. Siempre que estimamos, estamos mirando hacia el futuro y aceptamos resignados 
cierto grado de incertidumbre. 

Aunque la estimación es más un arte que una ciencia, es una actividad importante que no 
debe llevarse a cabo de forma descuidada. Existen técnicas Útiles para la estimación del esfuer- 
zo y del tiempo. Las métricas del proyecto y del proceso proporcionan una perspectiva histó- 
rica y una potente introducción para generar estimaciones cuantitativas. La experiencia anterior 
(de todas las personas involucradas) puede ayudar en gran medida al desarrollo y revisión de 
las estimaciones. Y, dado que la estimación es la base de todas las demás actividades de pla- 
nificación del proyecto, y que sirve como guía para una buena ingeniería del software, no esen 
absoluto aconsejable embarcarse sin ella. 


VISTAZO RÁPIDO 


¿Qué es? La planificación de un proyec- 


mas y productos basados encomputa- ¿Cuál es el producto obtenido? Se 


to de software realmente comprende 
todas las actividades tratadas en los 
Capítulos 5 al 9. Sin embargo, en el 
contexto de este capítulo, la planifica- 
ción implica la estimación —su inten- 
to por determinar cuánto dinero, 
esfuerzo, recursos, y tiempo supondrá 
construir un sistema o producto espe- 
cífico de software—. 


¿Quién lo hace? Los gestores del soft- 


ware —utilizandola información soli- 
citada alos clientes y a los ingenieros 
de software y los datos de métricas de 
software obtenidos de proyectos ante- 
riores—. 


¿Por qué es importante? ¿Podría cons- 


truir una casa sin saber cuanto estaría 
dispuesto a gastar?. Por supuesto que 
no, y puesto que la mayoría delos siste- 


dora cuestan considerablemente más 
que construir una casa grande, podría 
ser razonable desarrollar y estima antes 
de empezar a construir el software. 


¿Cuáles son los pasos? La estimación 


comienza con una descripción del 
ámbito del producto. Hasta que no se 
«delimita» el ámbito no es posible rea- 
lizar una estimación con sentido. El 
problema es entonces descompuesto 
en un conjunto de problemas de menor 
tamaño y cada uno de éstos se estima 
guiándose con datos históricos y con 
la experiencia. Es aconsejablerealizar 
las estimaciones utilizando al menos 
dos métodos diferentes (comocompro- 
bación). La complejidad y el riesgo del 
problema se considera antes dereali- 
zar una estimación final. 
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obtiene una tabla que indica las tare- 
as a desarrollar, las funciones aimple- 
mentar, y el coste, esfuerzo y tiempo 
necesario para la realización de cada 
una. También se obtiene una lista de 
recursos necesarios para el proyecto. 


¿Cómo puedo estar seguro de que 


lo he hecho correctamente? Esto 
es difícil, puesto que realmente no lo 
sabráhasta que el proyecto haya fina= 
lizado. Sinembargo, si tiene experien- 
cia y sigue un enfoque sistemático, 
realiza estimaciones utilizando datos 
históricos sólidos, crea puntos de esti- 
mación mediante al menos dos méto- 
dos diferentes y descompone la 
complejidad y riesgo, puede estar 
seguro de haber acertado plenamente. 
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A un destacado ejecutivo se le preguntó una vez por la 
característica más importante que debe tener un gestor 
de proyectos. Respondió: « ...uuna persona con la habi- 
lidad de saber qué es lo que va a ir mal antes de que ocu- 
rra...» . Debemos añadir: « ...y con el coraje para hacer 
estimaciones cuando el futuro no está claro...». 

La estimación de recursos, costes y planificacióntem- 
poral de un esfuerzo en el desarrollo de software requie- 
re experiencia, acceder a una buena información 
histórica y el coraje de confiar en predicciones (medi- 
das) cuantitativas cuando todo lo que existe son datos 
cualitativos. La estimación conlleva un riesgo inheren- 
te' y es este riesgo el que lleva a la incertidumbre. 


ques de estimación y dotos históricos 
ofrecen la mejor esperanza de que la realidad 
vencer sobre los demandas imposibles. 


La complejidad del proyecto tiene un gran efectoen la 
incertidumbre, que es inherente en la planificación. Sin 
embargo, la complejidades una medidarelativa que se ve 
afectada por la familiaridad con esfuerzos anteriores. Se 
podría considerar una aplicación sofisticadade comercio 
electrónico como «excesivamentecompleja» para un desa- 
rrollador que haya realizado su primera aplicación. Sin 
embargo para un equipo de software que desarrolle su 
enésimo sitio web de comercioelectrónico podría consi- 
derarse «sumamente fácil» (una de tantas). Se han pro- 
puesto una serie de medidas cuantitativasde la complejidad 
del software (por ejemplo, [Z2U597]). Tales medidas se 
aplican en el nivel de diseño y de codificación, y por con- 
siguiente son difíciles de utilizar durante la planificación 
del software (antes de que exista un diseño o un código). 
Sin embargo, al comienzo del proceso de planificación se 
pueden establecer otras valoraciones de complejidad más 
subjetivas (por ejemplo, los factores de ajuste de la com- 
plejidad del punto de función descritos en el Capítulo4). 

El tamaño del proyecto es otro factor importante que 
puede afectar a la precisión y a la eficiencia de las esti- 
maciones. A medida que el tamaño aumenta, crece rápi- 
damente*la interdependenciaentre varios elementos del 
software. El problema de la descomposición, un enfo- 
que importante hacia la estimación, se hace más difícil 
porque los elementos descompuestos pueden ser toda- 
vía excesivamente grandes. Parafraseando la ley de 
Murphy: «lo que puede ir mal irá mal», y si hay más 
cosas que puedan fallar, más cosas fallarán. 


1 En el Capítulo 6 se presentan técnicas sistemáticas para el análisis 
del riesgo. 


2 El tamaño se incrementa con frecuenciadebidoal cambio del ámbito» 
que ocurre cuando el cliente modifica los requisitos. El incremento del 
tamaño del proyecto puede tener un impacto geométrico en el coste y 
en la planificación del proyecto [MAH96]. 
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la complejidad del proyecto, el tamaño del proyecto y el 
grado de incertidumbre estructural afectan a la fiabilidad 
de la estimación. 


El grado de incertidumbre estructural tiene también 
efecto en el riesgo de la estimación. En este contexto, 
la estructura se refiere al grado en el que los requisitos 
se han definido, la facilidad con la que pueden subdi- 
vidirse funciones, y la naturaleza jerárquica de la infor- 
mación que debe procesarse. 

La disponibilidad de información histórica tiene una 
fuerte influencia en el riesgo de la estimación. Al mirar 
atrás, podemos emular lo que se ha trabajado y mejorar 
las áreas en donde surgieron problemas. Cuando se dis- 
pone de las métricas completas de software de proyectos 
anteriores (Capítulo4), se pueden hacer estimaciones con 
mayor seguridad; establecer planificaciones para evitar 
dificultades anteriores, y así reducir el riesgo global. 


3 auna inteligencia formada es 
Escansor sotistecha con el grado 

elo noturaleza de un asunto permite, 
exactitud cuando sólo una 
ión de la verdad es posible... 


El riesgo se mide por el grado de incertidumbre en las 
estimaciones cuantitativas establecidas por recursos, cos- 
te y planificación temporal. Sino se entiende bien el ámbi- 
to del proyecto o los requisitos del proyecto están sujetos 
a cambios, la incertidumbre y el riesgo son peligrosamen- 
te altos. El planificador del software debería solicitar defi- 
niciones completas de rendimiento y de interfaz (dentro 
de una especificación del sistema). El planificador y, lo que 
es más importante, el cliente, deben tener presente que 
cualquier cambio en los requisitos del software significa 
inestabilidad en el coste y en la planificación temporal. 

Sin embargo, un gestor de proyecto no debería obse- 
sionarse con la estimación. Los enfoques modernos de 
ingeniería del software (por ejemplo, modelos de pro- 
cesos evolutivos) toman un punto de vista iterativo del 
desarrollo. En tales enfoques, es posible? revisar la esti- 
mación (a medida que se conoce más información), y 
variarla cuando el cliente haga cambios de requisitos. 


3 Esto no significa que siempre sea aceptable políticamente modifi- 
car las estimaciones iniciales. Una organización de software madura 
y sus gestores reconocen que el cambio no es libre. Y sin embargo 
muchos clientes solicitan (incorrectamente) que una vez realizada la 
estimación debería mantenerse independientemente de que las cir- 
cunstancias cambien. 
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CAPITULO $ PLANIFICACION DE PROYECTOS DE SOFTWARE 


El objetivo de la planificación del proyecto de softwa- 
re es proporcionar un marco de trabajo que permita al 
gestor hacer estimaciones razonables de recursos, cos- 
te y planificación temporal. Estas estimaciones se hacen 
dentro de un marco de tiempo limitado al comienzo de 
un proyecto de software, y deberían actualizarse regu- 
larmente a medida que progresa el proyecto. Además, 
las estimaciones deberían definir los escenarios del 
«mejor caso» y «peor caso» de forma que los resulta- 
dos del proyecto puedan limitarse. 


El objetivo de la planificación se logra mediante un 
proceso de descubrimiento de la información que lleve 
a estimaciones razonables. En las secciones siguientes, 
se estudian cada una de las actividades asociadas a la 
planificación del proyecto de software. 


lo 


Cuanto más sepa, mejor realizará la estimación. 
Por consiguiente, actualice sus estimaciones 
a medida que progresa el proyecto. 


La primera actividad de la planificación del proyecto de 
softwarees determinar el ámbito del software. Se deben 


evaluar la función y el rendimiento que se asignaron al 
software durante la ingeniería del sistema de computa- 
dora (Capítulo 10), para establecer un ámbito de pro- 
yecto que no sea ambiguo, ni incomprensible para 
directivos y técnicos. Se debe delimitar la declaración 
del ámbito del software. 

El ámbito del software describe el control y los 
datos a procesar, la función, el rendimiento, las res- 
tricciones, las interfaces y la fiabilidad. Se evalúan las 
funciones descritas en la declaración del ámbito, y en 
algunos casos se refinan para dar más detalles antes 
del comienzo de la estimación. Dado que las estima- 
ciones del coste y de la planificación temporal están 
orientadas a la función, muchas veces es Útil llegar a 
un cierto grado de descomposición. Las consideracio- 
nes de rendimiento abarcan los requisitos de tiempo 
de respuesta y de procesamiento. Las restricciones 
identifican los límites del software originados por el 
hardware externo, por la memoria disponible y por 
otros sistemas existentes. 


5.3.1. Obtención de la información necesaria 
para el ámbito 


Al principio de un proyecto de software las cosas siem- 
pre están un poco borrosas. Se ha definido una necesi- 
dad y se han enunciado las metas y objetivos básicos, 
pero todavía no se ha establecido la información nece- 
saria para definir el ámbito (prerrequisito para la esti- 
mación). 

La técnica utilizada con más frecuencia para acercar 
al cliente y al desarrollador, y para hacer que comien- 
ce el proceso de comunicación es establecer una reu- 
nión O una entrevista preliminar. La primera reunión 
entre un ingeniero de software (el analista) y el cliente 
puede compararse a la primera cita entre adolescentes. 
Ninguna persona sabe lo que decir o preguntar; ambos 
están preocupados por si lo que dicen es mal interpre- 
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tado; ambos están pensando hasta dónde podrían llegar 
(probablemente los dos tienen aquí diferentes expecta- 
tivas); ambos quieren quitárselo pronto de encima; pero 
al mismo tiempo quieren que salga bien. 


, ¿Cómo debería empezar la 
comunicaciónentre el 
desarrolladory el cliente? 


Sin embargo, se debe iniciar la comunicación. Gau- 
se y Weinberg [GAUS9] sugieren que el analista comien- 
ce haciendo preguntas de contexto libre. Es decir, una 
serie de preguntas que lleven a un entendimiento bási- 
co del problema, las personas que están interesadas en 
la solución, la naturaleza de la solución que se desea y 
la efectividad prevista del primer encuentro. 

El primer conjunto de cuestiones de contexto libre se 
centran en el cliente, en los objetivos globales y en los 
beneficios. Por ejemplo, el analista podría preguntar: 


. ¿Quién está detrás de la solicitud de este trabajo? 

» ¿Quién utilizará la solución? 

+. ¿Cuál será el beneficio económico de una buena solu- 
ción? 

+ ¿Hay otro camino para la solución? 


Las preguntas siguientes permiten que el analista 
comprenda mejor el problema y que el cliente exprese 
sus percepciones sobre una solución: 

. ¿Cómo caracterizaría [el cliente] un resultado 


«correcto» que se generaría con una solución satis- 
factoria? 


+. ¿Con qué problema(s) se afrontará esta solución? 

. ¿Puede mostrarme (o describirme) el entorno en el 
que se utilizará la solución? 

+ ¿Hay aspectos O limitacionesespeciales de rendimiento 
que afecten a la forma en que se aborde la solución? 
La última serie de preguntas se centra en la efecti- 


vidad de la reunión. Gause y Weinberg las llaman «meta- 
cuestiones» y proponen la lista siguiente (abreviada): 
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+. ¿Esusted la persona apropiadapara responder a estas 
preguntas?¿Son «oficiales» sus respuestas? 
+ ¿Son relevantes mis preguntas para su problema? 


» ¿Estoy realizando muchas preguntas? 

+. ¿Hay alguien más que pueda proporcionar informa- 
ción adicional? 

+. ¿Hay algo más que debiera preguntarle? 


Estas preguntas (y otras) ayudarán a «romper el hie- 
lo» y a iniciar la comunicación esencial para establecer 
el ámbito del proyecto. Sin embargo, una reunión basa- 
da en preguntas y respuestas no es un enfoque que haya 
tenido un éxito abrumador. En realidad, la sesión P£R 
sólo se debería utilizar para el primer encuentro, reem- 
plazándose posteriormente por un tipo de reunión que 
combine elementos de resolución de problemas, nego- 
ciación y especificación. 

Los clientes y los ingenieros de software con fre- 
cuencia tienen establecido inconscientemente el pen- 
samiento de «nosotros y ellos». En lugar de trabajar 
como un equipo para identificar y refinar los requisi- 
tos, cada uno define su propio «territorio» y se comu- 
nica por medio de memorandos, documentos formales 
de situación, sesiones de preguntas y respuestas e infor- 
mes. La historia ha demostrado que este enfoque es 
muy pobre. Abundan los malentendidos, se omite infor- 
mación importante y nunca se establece una relación 
de trabajo con éxito. 


Referencia cruzada 


Las técnicas de obtención de requisitos se tratan 
enel Capítulo 11. 


Con estos problemas en mente un grupo de investi- 
gadores independientesha desarrolladoun enfoque orien- 
tado al equipo para la recopilación de requisitos que 
pueden aplicarse para ayudar a establecer el ámbito de 
un proyecto. Las técnicas denominadas técnicas para faci- 
litar las especificacionesde la aplicación (TFEA) (faci- 
litated application specification techniques [FAST]), 
pertenecen a un enfoque que alienta a la creación de un 
equipo compuesto de clientes y de desarolladoresque tra- 
bajen juntos para identificar el problema, proponer ele- 
mentos de solución, negociar diferentes enfoques y 
especificarun conjunto preliminar de requisitos. 


5.3.2. Viabilidad 


Una vez se ha identificado el ámbito (con la ayuda del 
cliente), es razonable preguntarse: «¿Podemos construir 
el software de acuerdo a este ámbito? ¿Es factible el 
proyecto?». Con frecuencia, las prisas de los ingenie- 
ros de software sobrepasan estas preguntas (oestán obli- 
gados a pasarlas por los clientes o gestores impacientes), 
solo se tienen en cuenta en un proyecto condenado des- 
de el comienzo. Putnam y Myers [PUT97a] tratan este 
aspecto cuando escriben: 
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o Chicago, tenemos lleno el tanque 
medio paquete de cigarrillos, está 


...no todo lo imaginablees factible, ni siquiera en el softwa- 
re, fugaz como puede aparecer un forastero. Por el contrario la 
factibilidad del software tiene cuatro dimensiones sólidas: Tec- 
nología—¿Es factible un proyecto técnicamente? ¿Está dentro 
del estado actual de la técnica? Financiación —¿Es factiblefinan- 
cieramente? ¿Puede realizarse a un coste asumible por la empre- 
sa de software y por el cliente? Tiempo—¿Pueden los proyectos 
adelantarse a los de la competencia? Recursos—¿La organiza- 
ción cuenta con los recursos suficientespara tener éxito? 

La respuesta es sencilla para algunos proyectos en ciertas 
áreas, ya que se ha hecho antes algún proyecto de este tipo. A 
las pocas horas, o, a veces, en pocas semanas de investigación, 
se puede estar seguro que se puede hacer de nuevo. 

Los proyectos de los que no se tiene experienciano son fáci- 
les. Un equipo puede pasarse varios meses descubriendo cuá- 
les son los requisitos principales, y cuáles son aquéllos difíciles 
de implementarpara una nueva aplicación. ¿Podría ocurrir que 
alguno de estos requerimientos presentara algunos riesgos que 
hicieran inviable el proyecto? ¿Podrían superarse estos ries- 
gos? El equipo de factibilidad debe asumir la arquitectura y el 
diseño de los requerimientos de alto riesgo hasta el punto de 
poder respondertodas estas preguntas. En algunos casos, cuan- 
doel equipo proporcionarespuestas negativas, esto puede nego- 
ciarse con una reducción de los requisitos. 

Mientras tanto, los altos ejecutivos están repicando sus dedos 
en la mesa. A menudo, mueven sus cigarros de forma elegan- 
te, pero de forma impaciente y rodeados de humo exclaman 
¡Ya es suficiente! ¡Hazlo! 

Muchos de estos proyectos que se han aprobadode esta for- 
ma aparecen a los pocos años en la prensa como proyectos 
defectuosos. 


Cions:of) 


El estudio de viabilidad es importante, pero las 
necesidades de la gestión son inclusa más importantes. 
No es bueno construir un producto o sistema de alta 
tecnología que en realidad nadie quiera. 


Putnam y Myers sugieren, de forma acertada, que el 
estudio del ámbito no es suficiente. Una vez que se ha 
comprendido el ámbito, tanto el equipo de desarrollo 
como el resto deben trabajar para determinar si puede 
ser construido dentro de las dimensionesreflejadas ante- 
riormente. Esto es crucial, aunque es una parte del pro- 
ceso de estimación pasada por alto a menudo. 


5.3.3. Un ejemplo de ámbito 


La comunicación con el cliente lleva a una definición 
del control y de los datos procesados, de las funciones 
que deben ser implementadas, del rendimiento y res- 
tricciones que delimitan el sistema, y de la información 
relacionada. Como ejemplo, consideremos el software 
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que se debe desarrollarpara controlar un sistema de cla- 
sificación de cinta transportadora (SCCT). La especifi- 
cación del ámbito del SCCT es la siguiente: 


El sistema de clasificación de cinta transportadora (SCCT) 
clasifica las cajas que se mueven por una cinta transportadora. 
Cada caja estará identificadapor un código de barras que con- 
tiene un número de pieza y se clasifica en uno de seis comparti- 
mentos al final de la cinta. Las cajas pasarán por una estación de 
clasificación que constade un lector de códigode barras y un PC. 
EL PC de la estación de clasificaciónestá conectado a un meca- 
nismo de maniobra que clasificalas cajas en los compartimen- 
tos. Las cajas pasan en orden aleatorio y están espaciadas 
uniformemente. La cinta se mueve a cinco pies por minuto. En 
la Figura 5.1 está representadoesquemáticamenteel SCCT. 


El softwaredel SCCTdeberecibirinformaciónde entradade 
un lector de código de barras a intervalos de tiempo que se ajus- 
ten a la velocidad de la cinta transportadora. Los datos del códi- 
go de barras se decodifican al formato de identificación de caja. 
El software llevaráa cabo una inspección en la base de datos de 
números de piezas que contiene un máximo de 1000 entradas 
para determinarla posición del compartimento adecuada para la 
caja que se encuentre actualmenteen el lector (estación de clasi- 
ficación). La posición correctadel compartimentose pasaráa un 
mecanismo de maniobra de ordenación que sitúa las cajas en el 
lugar adecuado. Se mantendrá una lista con los compartimentos 
destino de cada caja para su posteriorrecuperacióne informe. El 
softwaredel SCCTrecibirátambién entrada de un tacómetrode 
pulsos que se utilizará para sincronizar la señal de control del 
mecanismo de maniobra. Basándonos en el número de pulsos 
que se generen entre la estación de clasificacióny el mecanismo 
de maniobra, el software producirá una señal de control para que 
la maniobra sitúe adecuadamentela caja. 


Movimiento 
de la cinta transportadora 


de barras 


Conexión 
de control 


EODUCGO 


FIGURA 5.1. Un sistema de clasificación de cinta 
transportadora. 


El planificador del proyecto examina la especificación 
del ámbito y extrae todas las funciones importantes del 
software. Este proceso, denominadodescomposición, se 
trató en el Capítulo 3 y produce como resultado las fun- 
ciones siguientes”: 

* Lectura de la entrada del código de barras. 
+ Lectura del tacómetro de pulsos. 
» Descodificación de los datos del código de pieza. 


4 En realidad, la descomposición funcional se hace durante la inge- 
niena del sistema (Capítulo 10 ). El planificador utiliza la información 
obtenida a partir de la especificación del sistema para definir funcio- 
nes del software, 
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+ Búsqueda en la base datos. 
+ Determinar la posición del compartimento. 


+ Producción de la señal de control para el mecanismo 
de maniobra. 


+» Mantener una lista de los destinos de las cajas 


En este caso, el rendimiento está determinado por la 
velocidad de la cinta transportadora. Se tiene que termi- 
nar el procesamiento de cada caja antes de que llegue la 
siguiente caja al lector de código de barras. El software 
del SCCT está limitado por el hardware al que tiene que 
acceder—+l lector de código de barras, el mecanismo de 
maniobra, la computadora personal (PC)—, la memoria 
disponible y la configuración global de la cinta trans- 
portadora (cajas uniformemente espaciadas). 
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Ajuste lo estimación poro reflejar los requisitos 
del rendimiento y los restricciones del diseño difíciles, 
incluso si elámbito es sencillo. 


La función, el rendimiento y las restricciones se eva- 
lúan a la vez. Una misma función puede producir una 
diferencia de un orden de magnitud en el esfuerzo de 
desarrollo cuando se considera en un contexto con dife- 
rentes límites de rendimiento. El esfuerzo y los costes 
requeridos para desarrollar el software SCCT serían 
drásticamente diferentes si la función fuera la misma 
(por ejemplo: la cinta transportadora siguiese colocan- 
do cajas en contenedores), pero el rendimiento variará. 
Por ejemplo, si la velocidad media de la cinta transpor- 
tadora aumentara en un factor de 10 (rendimiento) y las 
cajas no estuvieran uniformemente espaciadas (una res- 
tricción), el software podría ser considerablemente más 
complejo — requiriendo,por tanto, un mayor esfuerzo 
de desarrollo —. La función, el rendimiento y las res- 
tricciones están íntimamente relacionadas. 


CLAVE 


la consideracióndel ámbito del sofwere debe contener 
una evaluación de todas las interfaces edemas. 


El software interactúa con otros elementos del sis- 
tema informático. El planificador considera la natura- 
leza y la complejidad de cada interfaz para determinar 
cualquier efecto sobre los recursos, los costes y la pla- 
nificación temporal del desarrollo. El concepto de inter- 
faz abarca lo siguiente: (1) hardware (por ejemplo: 
procesador, periféricos) que ejecuta el software y los 
dispositivos (por ejemplo: máquinas, pantallas) que están 
controlados indirectamente por el software; (2) softwa- 
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re ya existente (por ejemplo, rutinas de acceso a una 
base de datos, componentes de software reutilizables, 
sistemas operativos) que debe ser integrado con el nue- 
vo software; (3) personas que hacen uso del software 
por medio del teclado (terminales) u otros dispositivos 
de entrada/salida; (4)procedimientos que preceden o 
suceden al software en una secuencia de operaciones. 
En cada caso, debe comprenderse claramente la infor- 
mación que se transfiere a través de la interfaz. 


Si se ha desarrollado adecuadamente la especifica- 
ción del sistema (véase el Capítulo 10), casi toda la infor- 
mación requerida para la descripción del ámbito del 
software estará disponible y documentada antes de que 
comience la planificación del proyecto de software. En 
los casos en los que no haya sido desarrollada la espe- 
cificación, el planificador debe hacer el papel del ana- 
lista de sistemas para determinar las características y las 
restricciones que influirán en las tareas de estimación. 


La segunda tarea de la planificación del desarrollo de 
software es la estimación de los recursos requeridos para 
acometerel esfuerzo de desarrollode software.La Figu- 
ra 5.2 ilustra los recursos de desarrollo en forma de pirá- 
mide. En la base de la pirámide de recursos se encuentra 
el entorno de desarrollo — herramientas de hardware y 
software — que proporciona la infraestructura de sopor- 
te al esfuerzo de desarrollo. En un nivel más alto se 
encuentran los componentes de software reutilizables 
—los bloques de software que pueden reducir drástica- 
mente los costes de desarrollo y acelerar la entrega—. 
En la parte más alta de la pirámide está el recurso pri- 
mario — el personal —. Cada recurso queda especifica- 
do mediante cuatro características: descripción del 
recurso, informe de disponibilidad, fecha cronológica 
en la que se requiere el recurso, tiempo durante el que 
será aplicado el recurso. Las dos últimas características 
pueden verse como una ventana temporal. La disponi- 
bilidad del recurso para una ventana específica tiene que 
establecerse lo más pronto posible. 


¿Cuál es la fuente de 
nformación principal para 
determinar el ámbito? 


5.4.1. Recursos humanos 


El encargado de la planificación comienza elevando el 
ámbito y seleccionando las habilidades que se requieren 
para llevar a caboel desarrollo. Hay que especificartanto 
la posición dentro de la organización (porejemplo: gestor, 
ingeniero de software experimentado, etc.) como la espe- 
cialidad (por ejemplo: telecomunicaciones, bases de datos, 
cliente/servidor). Para proyectos relativamente pequeños 
(una persona-año O menos) una sola persona puede llevar 
a cabotodos los pasos de ingeniería del software, consul- 
tando con especialistas siempre que sea necesario. 

El número de personas requerido para un proyecto 
de software sólo puede ser determinado después de hacer 
una estimación del esfuerzo de desarrollo (por ejemplo, 
personas-mes). Estas técnicas de estimación del esfuer- 
zo se estudiarán después en este mismo capítulo. 


Personas 


- Componentes 


) software reutilizabl 


Herramientas 
hardware/software 


FIGURA 5.2. Recursos del proyecto. 


5.4.2. Recursos de software reutilizables 


La ingeniería del software basada en componentes 
(ISBCY destaca la reutilización - esto es, la creación 
y la reutilización de bloques de construcción de soft- 
ware [HOO91]—. Dichos bloques de construcción, lla- 
mados componentes, deben establecerse en catálogos 
para una consulta más fácil, estandarizarse para una fácil 
aplicación y validarse para una fácil integración. 


Bpapel que juegan las personas implicadas 
en el software y las organizacionesdel equipo 
al que pertenecen se tratan en el Capítulo 3. 


Bennatan [BEN92] sugiere cuatro categorías de 
recursos de software que se deberían tener en cuenta a 
medida que se avanza con la planificación: 


Componentes ya desarrollados. El software 
existente se puede adquirir de una tercera parte o 
provenir de uno desarrollado internamente para un 
proyecto anterior. Llamados componentes CCYD 
(componentes comercialmente ya desarrollados), 
estos componentes están listos para utilizarse en el 
proyecto actual y se han validado totalmente. 

Componentes ya experimentados. Especifica- 
ciones, diseños, código o datos de prueba existentes 


5 La ingeniería del software basada en componentes se trata con 
detalle en el Capítulo 27. 
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desarrolladospara proyectos anterioresque son simi- 
lares al software que se va a construir para el pro- 
yecto actual. Los miembros del equipo de software 
actual ya han tenido la experiencia completa en el 
área de la aplicación representada para estos com- 
ponentes. Las modificaciones, por tanto, requeridas 
para componentes de total experiencia, tendrán un 
riesgo relativamente bajo. 


: CLA VE 


Para que la reutilizaciónsea eficiente, los componentes 
de software deben estor catalogados, estondorizodos y 
validados. 


Componentes con experiencia parcial. Especi- 
ficaciones, diseños, código o datos de prueba exis- 
tentes desarrollados para proyectos anteriores que 
se relacionan con el software que se va a construir 
para el proyecto actual, pero que requerirán una 
modificación sustancial. Los miembros del equipo 
de software actual han limitado su experiencia sólo 
al área de aplicación representada por estos compo- 
nentes. Las modificaciones, por tanto, requeridas 
para componentes de experiencia parcial tendrán 
bastante grado de riesgo. 

Componentes nuevos. Los componentes de soft- 
ware que el equipo de software debe construir espe- 
cíficamente para las necesidades del proyecto 
actual. 


¿Qué aspectos debemos 
considerar cuando planificamos 
la reutilización de componentes de 
software existentes? 


Deberían ser consideradas las directrices siguientes 


por el planificador de software cuando los componen- 
tes reutilizables se especifiquen como recurso: 


L 


Si los componentes ya desarrollados cumplen los 
requisitos del proyecto, adquiéralos. El coste de la 
adquisición y de la integración de los componentes 
ya desarrollados serán casi siempre menores que el 
coste para desarrollar el software equivalente”. Ade- 
más, el riesgo es relativamente bajo. 


. Si se dispone de componentes ya experimentados, los 


riesgos asociados a la modificación y a la integración 


6 Cuando los componentes de software existentes se utilizan durante 
un proyecto, la reducción del coste global puede ser importante. En 
efecto, los datos de la industria indican que el coste, el tiempo de 
adquisición y el número de defectos entregados al cliente se redu- 
cen. 
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generalmente se aceptan. El plan del proyecto debe- 
ría reflejar la utilización de estos componentes. 


. Si se dispone de componentes de experiencia parcial 
para el proyecto actual, su uso se debe analizar con 
detalle. Si antes de que se integren adecuadamente 
los componentes con otros elementos del software 
se requiere una gran modificación, proceda cuida- 
dosamente - e l riesgo es alto—. El coste de modi- 
ficar los componentes de experiencia parcial algunas 
veces puede ser mayor que el coste de desarrollar 
componentes nuevos. 


De forma irónica, a menudo se descuida la utili- 
zación de componentes de software reutilizables 
durante la planificación, llegando a convertirse en la 
preocupación primordial durante la fase de desarro- 
llo del proceso de software. Es mucho mejor especi- 
ficar al principio las necesidades de recursos del 
software. De esta forma se puede dirigir la evaluación 
técnica de alternativas y puede tener lugar la adqui- 
sición oportuna. 


5.43. Recursos de entorno 


El entorno es donde se apoya el proyecto de software, 
llamado a menudo entorno de ingeniería del software 
(ElS), incorpora hardware y software. El hardware pro- 
porciona una plataforma con las herramientas (soft- 
ware) requeridas para producir los productos que son 
el resultado de una buena práctica de la ingeniería del 
software”. Como la mayoría de las organizaciones de 
software tienen muchos aspectos que requieren acce- 
so a EIS, un planificador de proyecto debe determinar 
la ventana temporal requerida para el hardware y el 
software, y verificar que estos recursos estarán dispo- 
nibles. 

Cuando se va a desarrollar un sistema basado en com- 
putadora (que incorpora hardware y software especia- 
lizado), el equipo de software puede requerir acceso a 
los elementos en desarrollo por otros equipos de inge- 
niería. Por ejemplo, el software para un control numé- 
rico (CN Jutilizado en una clase de máquina herramienta 
puede requerir una máquina herramienta específica (por 
ejemplo, el CN de un torno) como parte del paso de 
prueba de validación; un proyecto de software para el 
diseño de páginas avanzado puede necesitar un sistema 
de composición fotográfica o escritura digital en algu- 
na fase durante el desarrollo. Cada elemento de hard- 
ware debe ser especificado por el planificador del 
proyecto de software. 


7 Otro hardware —el Pot rno des. 
e 


que se Va a ejecutar no— es la enantados sobre la 


11 
software Poftresarse al usuario final, 
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Al principio, el coste del software constituía un peque- 
ño porcentaje del coste total de los sistemas basados 
en computadora. Un error considerable en las esti- 
maciones del coste del software tenía relativamente 
poco impacto. Hoy en día, el software es el elemen- 
to más caro de la mayoría de los sistemas informáti- 
cos. Para sistemas complejos, personalizados, un gran 
error en la estimación del coste puede ser lo que mar- 
que la diferencia entre beneficios y pérdidas. Sobre- 
pasarse en el coste puede ser desastroso para el 
desarrollador. 

La estimación del coste y del esfuerzo del software 
nunca será una cienciaexacta. Son demasiadas las varia- 
bles — humanas, técnicas, de entorno, políticas — que 
pueden afectar al coste final del software y al esfuerzo 
aplicado para desarrollarlo. Sin embargo, la estimación 
del proyecto de software puede dejar de ser un oscuro 
arte para convertirse en una serie de pasos sistemáticos 
que proporcionen estimaciones con un grado de riesgo 
aceptable. 


wfsourcing y competencia creciente, 
Lestimor de un modo más 
onvertido en un factor crítico de 
pora muchos grupos TÍ. 


Para realizar estimaciones seguras de costes y esfuer- 
zos tenemos varias opciones posibles: 


1. Dejar la estimación para más adelante (obviamente, 
¡podemos realizar una estimación al cien por cien 
fiable tras haber terminado el proyecto!). 


Basar las estimaciones en proyectos similares ya ter- 
minados. 


Utilizar «técnicas de descomposición» relativamente 
sencillas para generar las estimaciones de coste y de 
esfuerzo del proyecto. 


Utilizar uno O más modelos empíricos para la esti- 
mación del coste y esfuerzo del software. 


Desgraciadamente, la primera opción, aunque atrac- 
tiva, no es práctica. Las estimaciones de costes han de 
ser proporcionadasa priori. Sin embargo, hay que reco- 
nocer que cuanto más tiempo esperemos, más cosas 
sabremos, y cuanto más sepamos, menor será la pro- 
babilidad de cometer serios errores en nuestras esti- 
maciones. 

La segunda opción puede funcionar razonablemente 
bien, si el proyecto actual es bastante similar a los 
esfuerzos pasados y si otras influencias del proyecto 


a4 


(por ejemplo: el cliente, las condiciones de gestión, el 
EIS [Entorno de Ingeniería del software], las fechas 
límites) son similares. Por desgracia, la experiencia 
anterior no ha sido siempre un buen indicador de futu- 
ros resultados. 

Las opciones restantes son métodos viables para la 
estimación del proyecto de software. Desde un pun- 
to de vista ideal, se deben aplicar conjuntamente las 
técnicas indicadas; usando cada una de ellas como 
comprobación de las otras. Las técnicas de descom- 
posición utilizan un enfoque de «divide y vencerás)) 
para la estimación del proyecto de software. Median- 
te la descomposición del proyecto en sus funciones 
principales y en las tareas de ingeniería del software 
correspondientes, la estimación del coste y del esfuer- 
zo puede realizarse de una forma escalonada idónea. 
Se pueden utilizar los modelos empíricos de estima- 
ción como complemento de las técnicas de descom- 
posición, ofreciendo un enfoque de estimación 
potencialmente valioso por derecho propio. Cada 
modelo se basa en la experiencia (datos históricos) y 
toma como base: 


d=fí v;) 
donde d es uno de los valores estimados (por ejemplo, 
esfuerzo, coste, duración del proyecto) y los v,, son deter- 
minados parámetros independientes (por ejemplo, LDC 
o PF estimados). 

Las herramientas automáticas de estimación imple- 
mentan una o varias técnicas de descomposición O 
modelos empíricos. Cuando se combinan con una inter- 
faz gráfica de usuario, las herramientas automáticas son 
una opción atractiva para la estimación. En sistemas de 
este tipo, se describen las características de la organi- 
zación de desarrollo (por ejemplo, la experiencia, el 
entorno) y el software a desarrollar. De estos datos se 
obtienen las estimaciones de coste y de esfuerzo. 


Herramientas CASE 


Cada una de las opciones viables para la estimación 
de costes del software, sólo será buena si los datos his- 
tóricos que se utilizan como base de la estimación son 
buenos. Si no existen datos históricos, la estimación del 
coste descansará sobre una base muy inestable. En el 
Capítulo 4 examinamos las características de los datos 
de productividad del software y cómo pueden utilizar- 
se como base histórica para la estimación. 
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La estimación de proyectos de software es una forma 
deresolución de problemas y, en la mayoría de los casos, 
el problema a resolver (es decir, desarrollar estimacio- 
nes de coste y de esfuerzo para un proyecto de softwa- 
re) es demasiado complejo para considerarlo como un 
todo. Por esta razón, descomponemos el problema, vol- 
viéndolo a definir como un conjunto de pequeños pro- 
blemas (esperando que sean más manejables). 

En el Capítulo 3, se estudió el enfoque de descom- 
posición desde dos puntos de vista diferentes: descom- 
posición del problema y descomposición del proceso. 
La estimación hace uso de una o ambas formas de par- 
ticionamiento. Pero antes de hacer una estimación, el 
planificador del proyecto debe comprender el ámbito 
del software a construir y generar una estimación de su 
«tamaño». 


5.6.1, Tamaño del software 


La precisión de una estimación del proyecto de soft- 
ware se predice basándose en una serie de cosas: (1) el 
grado en el que el planificador ha estimado adecuada- 
mente el tamaño del producto a construir; (2) la habili- 
dad para traducir la estimación del tamaño en esfuerzo 
humano, tiempo y dinero (una función de la disponibi- 
lidad de métricas fiables de software de proyectos ante- 
riores); (3) el grado en el que el plan del proyecto refleja 
las habilidades del equipo de software, y (4)la estabi- 
lidad de los requisitos del software y el entorno que 
soporta el esfuerzo de la ingeniería del software. 


KO» 
“La VE 


El «tamaño» del software o tonstruir puede estimarse 
utilizando una medida diretto, LDC, o uno medido 
indirecto, PF. 


En esta sección, consideramosel problema del tama- 
ñodel software. Puesto que una estimación del proyec- 
to es tan buena como la estimación del tamaño del 
trabajo que va a llevarse a cabo, el tamaño representa 
el primer reto importante del planificador de proyectos. 
En el contexto de la planificación de proyectos, el tama- 
ño se refiere a una producción cuantificable del proyecto 
de software. Si se toma un enfoque directo, el tamaño 
se puede medir en LDC. Si se selecciona un enfoque 
indirecto, el tamaño se representa como PF. 

Putnam y Myers [PUT92] sugieren cuatro enfoques 
diferentes del problema del tamaño: 
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Tamaño en «lógica difusa». Este enfoque utiliza 
las técnicas aproximadas de razonamiento que son 
la piedra angular de la lógica difusa. Para aplicar este 
enfoque, el planificador debe identificar el tipo de 
aplicación, establecer su magnitud en una escala 
cuantitativa y refinar la magnitud dentro del rango 
original. Aunque se puede utilizar la experiencia per- 
sonal, el planificador también debería tener acceso 
a una base de datos histórica de proyectos” para que 
las estimaciones se puedan comparar con la expe- 
riencia real. 

Tamaño en punto de función. El planificador 
desarrolla estimaciones de características del domi- 
nio de información estudiadas en el Capítulo 4. 


¿Cómo medimos el 
'e* software que estamos 
planeando construir? 


Tamaño de componentes estándar. El software 
se compone de un número de «componentes están- 
dar» que son genéricos para un área en particular de 
la aplicación. Por ejemplo, los componentes están- 
dar para un sistema de información son: subsistemas, 
módulos, pantallas, informes, programas interacti- 
vos, programas por lotes, archivos, LDC e instruc- 
ciones para objetos. El planificador de proyectos 
estima el número de incidencias de cada uno de los 
componentes estándar, y utiliza datos de proyectos 
históricos para determinar el tamaño de entrega por 
componente estándar. Para ilustrarlo, considere una 
aplicación de sistemas de información. El planifica- 
dor estima que se generarán 18informes. Los datos 
históricos indican que por informe se requieren 967 
líneas de Cobol [PUT92]. Esto permite que el plani- 
ficador estime que se requieren 17.000LDC para el 
componente de informes. Para otros componentes 
estándar se hacen estimaciones y cálculos similares, 
y se producen resultados combinados de valores de 
tamaños (ajustados estadísticamente). 

Tamaño del cambio. Este enfoque se utiliza 
cuando un proyecto comprendela utilización de soft- 
ware existente que se debe modificar de alguna 
manera como parte de un proyecto. El planificador 
estima el número y tipo (por ejemplo: reutilización, 
añadir código, cambiar código, suprimir código) de 
modificacionesque se deben llevar a cabo. Mediante 
una «proporción de esfuerzo» [|PUT92] para cada tipo 
de cambio, se puede estimar el tamaño del cambio. 


8 Consulte la Sección 5.9 que trata brevemente las herramientas de 
estimación que utilizan una base de datos histórica y otras técnicas 
de tamaño estudiadas en esta sección. 
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Putnam y Myers sugieren que los resultados de cada 
uno de los métodos de tamaño señalados anteriormente 
se combinan estadísticamente para crear una estimación 
de tres puntos o del valor esperado. Esto se lleva a cabo 
desarrollandovalores de tamaño optimistas (bajos), y más 
probables, y pesimistas (altos), y se combinan utilizando 
la Ecuación (5.1) que se describe en la sección siguiente. 


5.6.2. Estimación basada en el problema 


En el Capítulo 4, las líneas de código (LDC) y los pun- 
tos de función (PF)se describieron como medidas bási- 
cas a partir de las que se pueden calcular métricas de 
productividad. Los datos de LDC y PF se utilizan de dos 
formas durante la estimación del proyecto de software: 
(1) como una variable de estimación que se utiliza para 
«dimensionar» cada elemento del software, y (2) como 
métricas de línea base recopiladas de proyectos anterio- 
res y utilizadas junto con variables de estimación para 
desarrollar proyecciones de coste y de esfuerzo. 

Las estimaciones de LDC y PF son técnicas de esti- 
mación distintas. Á pesar de que ambas tienen varias 
características en común. El planificador del proyecto 
comienza con un enfoque limitado para el ámbito del 
software y desde este estado intenta descomponer el 
software en funciones que se pueden estimar indivi- 
dualmente. Para cada función entonces se estiman las 
LDC y el PF (a variable de estimación). De forma alter- 
nativa, el planificador puede seleccionar otro compo- 
nente para dimensionar clases u objetos, cambios o 
procesos de gestión en los que puede tener impacto. 


¿Qué tienen en común la 
estimación orientada a PF 
y a LDC? 


Las métricas de productividad de línea base (por 
ejemplo: LDC/pm o PF/pm”) se aplican entonces para 
la variable de estimación adecuada y se extrae el coste 
o el esfuerzo de la función. Las estimaciones de fun- 
ción se combinan para producir una estimación global 
del proyecto entero. 


Consuof) 


Cuandose comparan métricas de productividadpara 
proyectos, esté seguro de estableceruna clasificación 
de los tipos de proyectos. Esto le permitirá calcular 
promedios para dominios específicos y la estimación 
seró mós exacto. 


Es importante señalar, sin embargo, que hay una sus- 
tancial diversidad en métricas de productividad, hacien- 


9 El acrónimo pm hace referencia a personas-mes 
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do sospechar que se utilice únicamente una métrica de 
productividad de línea base. En general, el dominio del 
proyecto debería calcularlas medias de LDC/pm o PF/pm. 
Es decir, los proyectos se deberían agrupar por tamaño 
de equipo, área de aplicación, complejidad y otros para- 
metros relevantes. Entonces se deberían calcular las 
medias del dominio local. Cuando se estima un proyec- 
to nuevo, primero se debería asignar a un dominio, y a 
continuación utilizar la media del dominio adecuado para 
la productividad al generar la estimación. Las técnicas 
de estimación de LDC y PF difieren en el nivel de deta- 
lle que se requiere para la descomposición y el objetivo 
de la partición. Cuando se utiliza LDC como variable de 
estimación, la descomposición"'es absolutamenteesen- 
cial y con frecuencia se toman para considerables nive- 
les de detalle. El enfoque de descomposición siguiente 
ha sido adaptado por Phillips [PHI98]'": 


CLAVE 


Poro. estimaciones de LDC, la descomposición 
se centro en las funciones del software. 


definir el ámbito del producto; 
identificarfunciones descomponiendo el ámbito; 
hacer mientras haya funciones 

seleccionar una función, 

asignar todas las funciones a la lista de subfunciones; 

hacer mientras haya subfunciones 

seleccionar una subfunción, 
si subfunción, =subfunción, descrita en una base 
de datos histórica 

anotar datos históricos del coste, 
esfuerzo, tamaño, (LDC o PE) para 
la subfuncióny ; 
ajustar datos históricos del coste, 
esfuerzo, tamaño basados en cual- 
quier diferencia: 
use datos del coste, esfuerzo, tama- 
ño ajustados para obtener una esti- 
mación parcial, E; 
estimación proyecto = suma de 
(E, + 
si se puede estimar coste, esfuerzo, 
tamaño (LDCo PF) para subfunción, 
entonces obtener estimación parcial, 


entonces 


sino 


estimación proyecto = suma de 

(BE) 

e subdividir subfunción, en sub- 

funciones más pequeñas; 

añadirlas a la lista de subfunciones; 
íin si 

íin si 
fin hacer 
fin hacer 


10 En general se descomponen las funciones del problema. Sin embargo. 
se puede utilizar una lista de componentesestándar (Sección5.6.1). 


1! El lenguaje informal de diseño del proceso señalado aquí se expone 
para ilustrar el enfoque general para el dimensionamiento. No tiene 
en cuenta ninguna eventualidad lógica. 


www.elsolucionario.net 


El enfoque de descomposición visto anteriormente asu- 
ne que todas las funciones pueden descomponerse en sub- 
funciones que podrán asemejarse a entradas de una base 
de datos histórica. Si este no es el caso, deberá aplicarse 
otro enfoque de dimensionamiento. Cuanto más grande 
sea el grado de particionamiento, más probable será que 
pueda desarrollar estimaciones de LDC más exactas. 

Para estimaciones de PF, la descomposición funcio- 
na de diferente manera. En lugar de centrarse en la fun- 
ción, se estiman cada una de las características del 
dominio de información —+entradas, salidas, archivos 
de datos, peticiones, e interfaces externas — y los cator- 
ce valores de ajuste de la complejidad estudiados en el 
Capítulo 4.Las estimaciones resultantes se pueden uti- 
lizar para derivar un valor de PF que se pueda unir a 
datos pasados y utilizar para generar una estimación. 


Para estimaciones de PF, la descomposición se centra en 
las característicasdel dominio de información. 


Con independencia de la variable de estimación que 
se utilice, el planificador del proyecto comienza por 
estimar un rango de valores para cada función o valor 
del dominio de información. Mediante los datos histó- 
ricos o (cuandotodo lo demás falla) la intuición, el pla- 
nificador estima un valor de tamaño optimista, más 
probable y pesimista para cada función, o cuenta para 
cada valor del dominio de información. Al especificar 
un rango de valores, se proporciona una indicación 
implícita del grado de incertidumbre. 


¿Cómo calcular el valor 
esperado para el tamaño del 
software? 


Entonces se calcula un valor de tres puntos o espe- 
rado. El valor esperado de la variable de estimación 
(tamaño), VE, se puede calcular como una media pon- 
derada de las estimaciones optimistas (S,,,), las más 

Da pt 
probables (S,,), y las pesimistas (5 


A ess). Por ejemplo, 
VES S opt + Win + Snes) 16 (5.1) 


da crédito a la estimación «más probable» y sigue una 
distribución de probabilidad beta. Se asume que existe 
una probabilidad muy pequeña en donde el resultado 
del tamaño real quedará fuera de los valores pesimistas 
y optimistas. 

Una vez que se ha determinado el valor esperado de 
la variable de estimación, se aplican datos históricos de 
productividad de LDC y PF. ¿Son correctas las estima- 
ciones? La única respuesta razonable a esto es: «No 
podemos estar seguros». Cualquier técnica de estima- 
ción, no importa lo sofisticada que sea, se debe volver 
a comprobar con otro enfoque. Incluso entonces, va a 
prevalecer el sentido común y la experiencia. 


pess 
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5.6.3. Un ejemplo de estimación basada en LDC 


Como ejemplo de técnicas de estimación de LDC y PE, 
tomemos en consideración un paquete de software a 
desarrollarse para una aplicación de diseño asistido por 
computadora (computer-aided design, CAD) de com- 
ponentes mecánicos. Una revisión de la especificación 
del sistema indica que el software va a ejecutarse en una 
estación de trabajo de ingeniería y que debe interconec- 
tarse con varios periféricos de gráficos de computadora 
entre los que se incluyen un ratón, un digitalizador, una 
pantalla a color de alta resolución y una impresora láser. 

Utilizando como guía una especificación de sistema, 
se puede desarrollar una descripción preliminar del 
ámbito del software: 

El software de CAD aceptará datos geométricos de dos y 
tres dimensiones por parte del ingeniero. El ingeniero se inter- 
conectará y controlará el sistema de CAD por medio de una 
interfaz de usuario que va a exhibir las características de un 
buen diseño de interfaz hombre-máquina. Una base de datos 
de CAD contiene todos los datos geométricos y la informa- 
ción de soporte. Se desarrollarán módulos de análisis de dise- 
ño para producir la salida requerida que se va a visualizaren 
varios dispositivos gráficos. El software se diseñará para con- 
trolar e interconectar dispositivos periféricos entre los que 
se incluyen un ratón, un digitalizador, una impresora láser y 
un trazador gráfico (plotter). 


La descripción anterior del ámbito es preliminar 
—no0 está limitada —. Para proporcionar detalles con- 
cretos y un límite cuantitativo se tendrían que ampliar 
todas las descripciones. Por ejemplo, antes de que la 
estimación pueda comenzar, el planificador debe 
determinar qué significa «características de un buen 
diseño de interfaz hombre-máquina» y cuál será el 
tamaño y la sofisticación de la «base de datos de 
CAD». 

Para estos propósitos, se asume que ha habido más 
refinamiento y que se identifican las funciones de soft- 
ware siguientes: 


+ interfaz de usuario y facilidades de control (IUEC), 

+ análisis geométrico de dos dimensiones (AG2D), 

+ análisis geométrico de tres dimensiones (AG3D), 

+ gestión de base de datos (GBD), 

+. facilidades de presentación gráfica de computadora 
(FPGO), 

+ control de periféricos (CP), 

+. módulos de análisis del diseño (MAD). 


Cionsuo 


Muchas aplicaciones modernos residen en uno red o son 
porte de uno arquitectura cliente/servidor. Por 
consiguiente, esté seguro que sus estimaciones contienen 
el esfuerzo requerido para el desarrollo del sofware de la 
«infraestructura», 


Siguiendo la técnica de descomposición de LDC, se 
desarrolla la tabla de estimación mostrada en la Figura 
5.3. Se desarrolla un rango de estimacionesde LDC para 
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cada función. Por ejemplo, el rango de estimaciones 
de LDC de la función del análisis geométrico de tres 
dimensiones es: optimista 4.600 LDC—=, más pro- 
bable —6.900—, y pesimista —8.600LDC—, Apli- 
cando la Ecuación (5.1), el valor esperado de la función 
del análisis geométrico es 6.800 LDC. Este número se 
introduce en la tabla. De forma similar se derivan otras 
estimaciones. Sumando en vertical la columna esti- 
mada de LDC, se establece una estimación de 33.200 
líneas de código para el sistema de CAD. 


Cons: 


Nosucumba o lo tentación de utilizar este resultadocomo 
estimación. Debería obtener otroestimación utilizando 
un método diferente. 


Una revisión de datos históricos indica que la pro- 
ductividad media de la organización para sistemas de 
este tipo es de 620 LDC/pm. Según una tarifa laboral 
de E8.000 por mes, el coste por línea de código es apro- 
ximadamente de £13,00. Según la estimación de LDC 
y los datos de productividad históricos, el coste total 
estimado del proyecto es de £431.000 y el esfuerzo esti- 
mado es de 54 personas-mes””. 


Función LDC estimada 
Interface del usuario y facilidades de control (IUFC) 2.300 
Análisis geométrico de dos dimensiones (AG2D) 5.300 
Análisis geométrico de tres dimensiones (A32D) 6.800 
Gestión de base de datos (GBD) 3.350 
Facilidadesde presentación gráfica 

de computadora (FPGC) 4.950 
Control de periféricos (CP) 2.100 
Módulos de análisis del diseño (MAD) 8.400 
Líneas de códigos estimadas 


FIGURA 5.3. Tabla de estimación para el método de LDC. 


5.6.4. Un ejemplo de estimación basada en PF 


La descomposición de estimación basada en PF se cen- 
tra en los valores de dominio de información, y no en 
las funciones del software. Teniendo en cuenta la tabla 
de cálculos de punto de función presentada en la Figu- 
ra 5.4, el planificador del proyecto estima las entradas, 
salidas, peticiones, archivos e interfaces externas del 
software de CAD. Para los propósitos de esta estima- 
ción, el factor de ponderación de la complejidad se asu- 
me como la media. La Figura 5.4 presenta los resultados 
de esta estimación. 


12 La estimación se redondea acercándose lo más posible a El.000 y 
persona—-mes. 
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Referencia Web 


Se puede obtener información sobre las herramientas de 
estimación del coste mediante PF en www.spr.com 


Valor de dominio 

de información 
Nlérriero de erttradas 
Número de salidas 


Opt Probable Pes. Cuenta Peso  CuentaPF 
est, 


Número de peticiones 
Número de archivos 
Número de interfaces 
externas 


Cuenta total 


FIGURA 5.4. Estimación de los valores del dominio 
de información. 


Como se describe en el Capítulo 4, se estima cada 
uno de los factores de ponderación de la complejidad, 
y se calcula el factor de ajuste de la complejidad: 

Factor Valor 
Copia de seguridad y recuperación 
Comunicaciones de datos 
Proceso distribuido 
Rendimiento crítico 
Entorno operativo existente 
Entrada de datos en línea (on-line) 
Transacciones de entrada en múltiples 

pantallas 
Archivos maestros actualizados en línea 

(on-line) 

Complejidad de valores del dominio 

de información 
Complejidad del procesamiento interno 
Código diseñado para la reutilización 
Conversión/instalación en diseño 
Instalaciones múltiples 
Aplicación diseñada para el cambio 
Factor de ajuste de la complejidad 


bhbURhOn- 


UU Bn un 


1,17 


Finalmente, se obtiene el número estimado de PF: 


PE ctimago = Cuenta total X [0,65 +0,01 x 2(F; )1 
375 


PF 


estimado — 


La productividad media organizacionalpara sistemas 
de este tipo es de 6,5 PF/pm. Según la tarifa laboral de 
E3.000 por mes, el coste por PFes aproximadamente de 
E1.230. Según la estimación de LDC y los datos de pro- 
ductividad históricos, el coste total estimadodel proyecto 
es de £461.000, y el esfuerzo estimado es de 58 perso- 
nas/mes. 
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5.6.5. Estimación basada en el proceso 


Ta técnica más común para estimar un proyecto es basar 
la estimación en el proceso que se va a utilizar. Es decir, 
el proceso se descompone en un conjunto relativamen- 
te pequeño de actividades O tareas, y en el esfuerzo 
requerido para llevar a cabo la estimación de cada tarea. 


Al igual que las técnicas basadas en problemas, la 
estimación basada en el proceso comienza con un esbo- 
zo de las funciones del software obtenidas a partir del 
ámbito del proyecto. Para cada función se debe llevar 
a cabo una serie de actividades del proceso de softwa- 
re. Las funciones y las actividades del proceso de soft- 
ware relacionadas se pueden representar como parte de 
una tabla similar a la presentada en la Figura 3.2. 


Etmarco de trabajo común del proceso (MCP) 
se estudio en el Capítulo 2, 


Una vez que se mezclan las funciones del proble- 
ma y las actividades del proceso, el planificador esti- 
ma el esfuerzo (por ejemplo: personas-mes) que se 
requerirá para llevar a cabo cada una de las activida- 
des del proceso de software en cada función. Estos 
datos constituyen la matriz central de la tabla de la 
Figura 3.2. Los índices de trabajo medios (es decir, 
esfuerzo coste/funidad) se aplican entonces al esfuer- 
zo estimado a cada actividad del proceso. Es muy pro- 
bable que en cada tarea varíe el índice de trabajo. El 
personal veterano se involucra de lleno con las pri- 
meras actividades y generalmente es mucho más caro 
que el personaljunior, quienes están relacionados con 
las tareas de diseño posteriores, con la generación del 
código y con las pruebas iniciales. 


Actividad Planificació! 


¡Análisis Construcción 
Ingenieria EC ¡Totales 
de riesg An 9 Entrega 


A 


EEES 
7 ECN HN 2.00 7135 
AnS 

0.75 1.50_| n/a 5.75 

! 150 [n/a] 4.25 | 

al 5.00 | 


0C = Comunicación cliente EC = Evaluación cliente 


FIGURA 5.5. Tabla de estimación basada en el proceso. 


Como último paso se calculan los costes y el esfuer- 
zo de cada función, y la actividad del proceso de soft- 
ware. Si la estimación basada en el proceso se realiza 
independientementede la estimación de LDC o PEF, aho- 
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ra tendremos dos o tres estimaciones del coste y del 
esfuerzo que se pueden comparar y evaluar. Si ambos 
tipos de estimaciones muestran una concordancia razo- 
nable, hay una buena razón para creer que las estima- 
ciones son fiables. Si, por otro lado, los resultados de 
estas técnicas de descomposición muestran poca con- 
cordancia, se debe realizar más investigación y análisis. 


5.6.6. Un ejemplo de estimación basada 
en el proceso 


Para ilustrar el uso de la estimación basada en el pro- 
ceso, de nuevo consideremos el software de CAD pre- 
sentadoen la Sección 5.6.3. La configuración del sistema 
y todas las funciones del software permanecen iguales 
y están indicadas en el ámbito del proyecto. 


Cons 


Siel tiempolo permite, realice uno mayor 
descomposición al especificar /as tareas; en la Figura 5,5, 
p. él, se divide el análisis ensus tareasprincipales y se 
estima coda una por separado. 


En la tabla de estimación de esfuerzos ya termina- 
da, que se muestra en la Figura 5.5 aparecen las esti- 
maciones de esfuerzo (en personas-mes) para cada 
actividad de ingeniería del software proporcionada para 
cada función del software de CAD (abreviada para 
mayorrapidez). Las actividadesde ingeniería y de cons- 
trucciónlentrega se subdividen en las tareas principa- 
les de ingeniería del software mostradas. Las estima- 
ciones iniciales del esfuerzo se proporcionan para la 
comunicación con el cliente, planificación y análisis de 
riesgos. Estos se señalan en la fila Total en la parte infe- 
rior de la tabla. Los totales horizontales y verticales pro- 
porcionan una indicación del esfuerzo estimado que se 
requiere para el análisis, diseño, codificación y pruebas. 
Se debería señalar que el 53 por 100 de todo el esfuer- 
zo se aplica en las tareas de ingeniería «frontales» (aná- 
lisis y diseño de los requisitos) indicando la importancia 
relativa de este trabajo. 

Basado en una tarifa laboral de £5.000 por mes, el 
coste total estimado del proyecto es de £230.000 y el 
esfuerzo estimado es de 46 personas/ímes. A cada acti- 
vidad de proceso del software o tareas de ingeniería del 
software se le podría asociar diferentes índices de tra- 
bajo y calcularlos por separado. 

El esfuerzo total estimado para el software de CAD 
oscila de un índice bajo de 46 personas-mes (obtenido 
mediante un enfoque de estimación basado en el pro- 
ceso) a un alto de 58 personas-mes (obtenido median- 
te un enfoque de estimación de PF). La estimación media 
(utilizando los tres enfoques) es de 53 personas-mes. 
La variación máxima de la estimación media es apro- 
ximadamente del 13 por ciento. 

¿Qué ocurre cuando la concordancia entre las esti- 
maciones es mala? Para responder aesta pregunta se ha 
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de reevaluar la información que se ha utilizado para 
hacer las estimaciones. 

Muchas divergencias entre estimaciones se deben a 
una de dos causas: 


Cons) 


No espere que todos los estimaciones coincidan 
en uno o dos porcentajes. Silo estimación está 
dentrode uno banda del 20 por 100, puede 
reconciliarse en un Único valor. 


1. No se entiende adecuadamente el ámbito del pro- 
yecto o el planificador lo ha mal interpretado. 


NN 


Los datos de productividad usados para técnicas de 
estimación basados en problemas no son apropiados 
para la aplicación, están obsoletos (ya no reflejan con 
precisión la organización de la ingeniería del soft- 
ware), o se han aplicado erróneamente. 


El planificador debe determinar la causa de la diver- 
gencia y conciliar las estimaciones. 


Un modelo de estimación para el software de computa- 
dora utiliza fórmulas derivadas empíricamentepara pre- 
decir el esfuerzo como una función de LDC o PF. Los 
valores para LDC o PF son estimados utilizando el enfo- 
que descritoen las Secciones 5.6.2 y 5.6.3. Pero en lugar 
de utilizar las tablas descritas en esas secciones, los valo- 
res resultantes para LDC o PF se unen al modelo de esti- 
mación. Los datos empíricos que soportan la mayoría 
de los modelos de estimación se obtienen de una mues- 
tra limitada de proyectos. Por esta razón, el modelo de 
estimación no es adecuado para todas las clases de soft- 
ware y en todos los entornos de desarrollo. Por consi- 
guiente, dos resultados obtenidos de dichos modelos se 
deben utilizar con prudencia'”. 


5.7.1. La estructura de los modelos de estimación 


e 
CLAVE 


Un modelo de estimación refleja lo cantidad de proyectos 
a partir de donde se ha obtenido. Por consiguiente, 
el modelo es susceptible al dominio. 


Un modelo común de estimación se extrae utilizando el 
análisis de regresión sobre los datos recopilados de pro- 
yectos de software anteriores. La estructura global de 
tales modelos adquiere la forma de [MAT94]: 


E=A+Bx(ev)ó (5.2) 


donde A, B y C son constantes obtenidas empíricamen- 
te, Ees el esfuerzo en personas-mes, y ev es la variable 
de estimación (de LDC o PF). Además de la relación 


13 En general se debería calibrar un modelo de estimación para las 
condiciones locales. El modelo se debería ejecutar utilizando los resul- 
tados de proyectosterminados. Los datos previstos por el modelo se 
deberían comparar con los resultados reales, y la eficacia del modelo 
(para condiciones locales) debería ser evaluada. Si la concordancia 
no es buena, los coeficientes del modelo se deben volver a calcular 
utilizando datos locales. 


señalada en la Ecuación (5.2) la mayoría de los mode- 
los de estimación tienen algún componente de ajuste del 
proyecto que permite ajustar E por otras características 
del proyecto (por ejemplo: complejidad del problema, 
experiencia del personal, entorno de desarrollo). Entre 
los muchos modelos de estimación orientados a LDC 
propuestos en la bibliografía se encuentran los siguien- 
tes: 

E=5,2x (KLDC)” 

E =5,5+0,73 x 

(KLDC)'' 
E=3,2x (KLDC)'% 
E =5,288x (KLDC)'"" 


Modelo de Walston-Felix 


Modelo de Bailey-Basili 
Modelo simple de Boehm 
Modelo Doty para KLDC > 9 


También se han propuesto los modelos orientados a 
PF. Entre estos modelos se incluyen: 


E =-13,39+0,0545PF Modelo de Albretch 
y Gaffney 
E=60,62 x 7,728 x 
x 10* pF? 
E =585,7 + 15,12 PF 


Modelo de Kemerer 


Modelo de Matson, Bamett 
y Mellichamp 


Un rápido examen de los modelos listados anterior- 
mente indica que cada uno producirá un resultado dife- 
rente'* para el mismo valor de LDC y PF. La implicación 
es clara. Los modelos de estimación se deben calibrar 
para necesidades locales. 


Consuof) 


Ninguno de estos modelos debería ser aplicado 
Inodecuodomenteo su entorno. 


14 Esta referencia se fundamenta en que estos modelos a menudo se 
derivan de un número relativamente pequeño de proyectos sólo en 
unos cuantos dominios de la aplicación. 
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5.7.2, El modelo COCOMO 


Barry Boehm [BOE81], en su libro clásico sobre «eco- 
nomía de la ingeniería del software», introduce una jerar- 
quía de modelos de estimación de software con el 
nombre de COCOMO, por Constructive Cost Model 
(Modelo Constructivo de Coste). El modelo COCOMO 
original se ha convertido en uno de los modelos de esti- 
mación de coste del software más utilizados y estudia- 
dos en la industria. El modelo original ha evolucionado 
a un modelo de estimación más completo llamado 
COCOMO II [BOE 96, BOE 00]. Al igual que su pre- 
decesor, COCOMO lles en realidad una jerarquía de 
modelos de estimación que tratan las áreas siguientes : 


Modelo de composición de aplicación. Utilizado 
durante las primeras etapas de la ingeniería del soft- 
ware, donde el prototipado de las interfaces de usua- 
rio, la interacción del sistema y del software, la 
evaluación del rendimiento, y la evaluación de la 
madurez de la tecnología son de suma importancia. 

Modelo de fase de diseño previo. Utilizado una 
vez que se han estabilizado los requisitos y que se 
ha establecidola arquitectura básica del software. 


Modelo de fase posterior a la arquitectura. Uti- 
lizado durante la construcción del software. 


Al igual que todos los modelos de estimación del 
software, el modelo COCOMO II descrito antes nece- 
sita información del tamaño. Dentro de la jerarquía del 
modelo hay tres opciones de tamaño distintas: puntos 
objeto, puntos de función, y líneas de código fuente. 

El modelo de composición de aplicación COCOMO 
Il utiliza los puntos objeto como se ilustra en los párrafos 
siguientes. Debería señalarse que también están disponi- 
bles otros modelos de estimación más sofisticados (utili- 
zando PF y KLDC) que forman parte del COCOMOTII, 


Referencia 


Se puede obtener información detallada sobre el 
COCOMO tl, incluyendo software que puede descargar, en 
sunset.usc.edu/COCOMON/cocomo.html 


Del mismo modo que los puntos de función (Capí- 
tulo 4), el punto objeto es una medida indirecta de soft- 
ware que se calcula utilizando el total de (1) pantallas 
(dela interface de usuario), (2) informes, y (3)compo- 
nentes que probablemente se necesiten para construir 
la aplicación. Cada instancia de objeto (por ejemplo, 
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una pantalla o informe) se clasifica en uno de los tres 
niveles de complejidad (esto es, básico, intermedio, o 
avanzado) utilizando los criterios sugeridos por Boehm 
[BOE96]. En esencia, la complejidad es una función del 
número y origen de las tablas de datos del cliente y ser- 
vidor necesario para generar la pantalla o el informe y 
el número de vistas O secciones presentadas como par- 
te de la pantalla o del informe. 


P | | 
Tipo de objeto eso de la Complejidad 


| Básico | Intermedio] Avanzado | Intermedio | Básico | Intermedio] Avanzado | Avanzado 


SETI UCI INTO NC 
e 


| Componente 136] Í 


TABLA 5.1. Factores de peso de la complejidad para tipos 
de objeto [BOE96]. 


Una vez que se ha determinado la complejidad, se 
valora el número de pantallas, informes, y componen- 
tes de acuerdo con la Tabla 5.1. La cuenta de punto obje- 
to se determina multiplicando el número original de 
instancias del objeto por el factor de peso de la tabla 5.1 
y se suman para obtener la cuenta total de punto obje- 
to. Cuando se va a aplicar el desarrollo basado en com- 
ponentes O la reutilización de software en general, se 
estima el porcentaje de reutilización (%reutilización) y 
se ajusta la cuenta del punto objeto: 


PON = (puntos objeto) x [(100 - %reutilización)/100] 


donde PON significa «puntos objeto nuevos». 


Qué es un «punto objeto)? 


Para obtener una estimación del esfuerzo basada en el 
valor PON calculado, se debe calcular la «proporción de 
productividad». La Tabla 5.2 presenta la proporción de 
productividad para los diferentes niveles de experiencia 
del desarrolladory de madurez del entorno de desarrollo. 
Una vez determinada la proporción de productividad, se 
puede obtener una estimación del esfuerzo del proyecto: 


Esfuerzo estimado = PON / PROD 


En modelos COCOMO II más avanzados'', se 
requiere una variedad de factores de escala, conducto- 
res de coste y procedimientos de ajuste. Un estudio com- 
pleto de estos temas están fuera del ámbito de este libro. 
El lector interesado debería consultar [BOEOO] O visi- 
tar el sitio web COCOMO II. 


15 Como se señaló anteriormente, estos modelos hacen uso de las 
cuentas de PF y KLDC para la variable tamaño. 
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Experiencia/capacidad 
del desarrollador 


Baja [Normal | Alta 


Madurez/capacidad 
del entorno 


Baja |Normal| Alta 


TABLA 5.2. Proporciones de productividad para puntos 
objeto [BOE96]. 


5.73. La ecuación del software 


La ecuación del software[PUT92] es un modelo multiva- 
riable dinámico que asume una distribuciónespecífica del 
esfuerzo a lo largo de la vida de un proyecto de desarrollo 
de software. El modelo se ha obtenido a partir de los datos 
de productividad para unos 4.000 proyectos actuales de 
software, un modelo de estimación tiene esta forma: 


E = [LDCx BP Y x (1/4) (5.3) 
donde 


E =esfuerzo en personas-mes O personas-año, 
£ = duración del proyecto en meses o años, 

B = «factor especial de destrezas»'*, 

P =«parámetro de productividad» que refleja: 


» Madurez global del proceso y de las prácticas 
de gestión. 

+ La amplitud hasta donde se utilizan correcta- 
mente las normas de la ingeniería del software. 

+ El nivel de los lenguajes de programación uti- 
lizados. El estado del entorno del software. 

» Las habilidades y la experiencia del equipo del 
software. 

+ La complejidad de la aplicación. 


Los valores típicos para el desarrollo del software 
empotrado en tiempo real podrían ser P = 2.000; 
P = 10.000para telecomunicaciones y software de sis- 
temas; y P = 28.000 para aplicaciones comerciales de 


En muchas áreas de aplicación del software, a menu- 
does más rentable adquirir el software de computado- 
ra que desarrollarlo. Los gestores de ingeniería del 
software se enfrentan con una decisión desarrollar o 
comprar que se puede complicaraún más con las opcio- 
nes de adquisición: (1) el software se puede comprar 
(con licencia) ya desarrollado; (2) se pueden adquirir 


16 B se incrementa lentamente a medida que crecen «la necesidad de 
integración, pruebas, garantía de calidad, documentación y habilidad 
de gestión» [PUT92]. Para programas pequeños (KLDC=5a 15).B = 
0,16.Para programas mayores de 70 KLDC, B = 0,39. 
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sistemas'”, El parámetro de productividad se puede ex- 
traer para las condiciones locales mediante datos histó- 
ricos recopilados de esfuerzos de desarrollo pasados. 


Referencia Web 


Se puede obtener información de las herramientas de 
estimación del coste del software que se han desarrollado 
a partir de la ecuación del software en www.qsm.com 


Es importante señalar que la ecuación del software 
tiene dos parámetros independientes: (1) una estima- 
ción del tamaño (en LDC) y (2) una indicación de la 
duración del proyecto en meses o años. 

Para simplificar el proceso de estimación y utilizar 
una forma más común para su modelo de estimación, 
Putnam y Myers sugieren un conjunto de ecuaciones 
obtenidas de la ecuación del software. Un tiempo míni- 
mo de desarrollo se define como: 


Umin =8,14 (LDC/PY% en meses para £, >Ómeses (5.4) 


E = 180BY en personas-mes para E> 20 personas-mes (5.4b) 


Tenga en cuenta que t en la ecuación (5.4b) se repre- 
senta en años. 

Mediante las ecuaciones (5.4) con P= 12.000 (valor 
recomendado para software científico) para el softwa- 
re de CAD estudiado anteriormente en este capítulo, 


trip =8,14 (33.200 / 12.000) 


Umin = 12,6 meses 


E=180x 0,28 x (1,05) 
E=58 personas-mes 


Los resultados de la ecuación del software se corres- 
ponde favorablemente con las estimaciones desarrolla- 
das en la Sección 5.6. Del mismo modo que el modelo 
COCOMO expuesto en la sección anterior, la ecuación 
del software ha evolucionado durante la década pasa- 
da. Se puede encontrar un estudio de la versión exten- 
dida de este enfoque de estimación en [PUT97]. 


ir 


componentes de software «totalmente experimentado» 
o «parcialmente experimentado» (Consulte la Sección 
5.4.2), y entonces modificarse e integrarse para cum- 
plir las necesidades específicas, o (3)el software pue- 
de ser construido de forma personalizada por una 
empresa externa para cumplir las especificaciones del 
comprador. 


17 Es importante destacar que el parámetro de productividad puede 
obtenerse empíricamente de los datos locales de un proyecto. 
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Los pasos dados en la adquisición del software se 
definen según el sentido crítico del software que se va 
a comprar y el coste final. En algunos casos (por ejem- 
plo: software para PC de bajo coste) es menos caro com- 
prar y experimentar que llevar a cabo una larga 
evaluación de potenciales paquetes de software. Para 
productos de software más caros, se pueden aplicar las 
directrices siguientes: 


Í. Desarrollo de una especificación para la función y 
rendimiento del software deseado. Definición de las 
características medibles, siempre que sea posible. 


Consuof) 


Hoy veces en las que el software proporcionouna 
solución «perfecta» excepto poro algunos aspectos 
especialesde los que puede prescindir. En muchos cosos, 
¡merece lo peno vivir sin éstos! 


2. Estimación del coste interno de desarrollo y la fecha 
de entrega. 


3a.Selección de tres o cuatro aplicaciones candidatos 
que cumplan mejor las especificaciones. 


3b,Selección de componentes de software reutilizables 
que ayudarán en la construcción de la aplicación 
requerida. 

. 4. Desarrollo de una matriz de comparación que presente 
la comparación una a una de las funciones clave. Alter- 
nativamente, realizar el seguimiento de las pruebas de 
evaluación para comparar el software candidato. 

5. Evaluación de cada paquete de software o compo- 
nente según la calidad de productos anteriores, 
soporte del vendedor, dirección del producto, repu- 
tación, etc. 

Contacto con otros usuarios de dicho software y peti- 

ción de opiniones. 


Simple (0,30) £380.000 


Difícil (0,70) €450.000 


Cambios menores 
a 


) 


Construcción 
£275.000 


£310.000 


Simple (0,20; 


importantes 


(0,60) €490.000 


Complejo (0,80) 


Cambios menores 
(0,70 


€210.000 
Contrato 


Camblos €400.000 


importantes (0,30) 


Sin cambios 
(0,61 


€350.000 


Con cambios (0,40) ni 


FIGURA 5.6. Árbol de decisión para apoyar la decisión 
desarrollar-comprar. 
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CAPITULO > PLANIFICACION DE PROYECTOS DE SOFTWARE 


En el análisis final, la decisión de desarrollar—com- 
prar se basa en las condiciones siguientes: (1) ¿La fecha 
de entrega del producto de software será anterior que la 
del software desarrollado internamente? (2) ¿Será el 
coste de adquisición junto con el de personalización 
menor que el coste de desarrollo interno del software? 
(3) ¿Será el coste del soporte externo (por ejemplo: un 
contrato de mantenimiento) menor que el coste del 
soporte interno? Estas condiciones se aplican a cada una 
de las opciones señaladas anteriormente. 


5.8.1. Creación de un árbol de decisiones 


Los pasos descritos anteriormente se pueden especifi- 
car mediante técnicas estadísticas tales como el análi- 
sis del árbol de decisión [BOE89]. Por ejemplo, la 
Figura 5.6 representa un árbol de decisión para un sis- 
tema X basado en software. En este caso, la organiza- 
ción de la ingeniería del software puede (1) construir el 
sistema X desde el principio; (2) reutilizar los compo- 
nentes existentes de «experiencia parcial» para cons- 
truir el sistema; (3) comprar un producto de software 
disponible y modificarlo para cumplir las necesidades 
locales; o (4) contratar el desarrollo del software a un 
vendedor externo. 


¿Existe un método sistemático para 
ordenar las opciones relacionadas con 
la decisión desarrollar-comprar? 


Si se va a construir un sistema desde el principio, 
existe una probabilidad del 70 por 100 de que el tra- 
bajo sea difícil. Mediante las técnicas de estimación 
estudiadas en este capítulo, el planificador del pro- 
yecto estima que un esfuerzo de desarrollo difícil cos- 
tará £450.000. Un esfuerzo de desarrollo «simple» se 
estima que cueste £380,000. El valor esperado del cos- 
te, calculado a lo largo de la rama del árbol de deci- 
sión es: 

coste esperado = Y, (probabilidad del camino), X (coste esti- 
mado del camino); 


donde ¡es el camino del árbol de decisión. Para el 
camino construir, 


coste esperado = 0,30 (£380K) + 0,70 (£450K) 


= £429K 


construcción 


También se muestran los otros caminos del árbol de 
decisión, los costes proyectados para la reutilización, 
compra y contrato, bajo diferentes circunstancias. Los 
costes esperados de estas rutas son: 


=0,40 (£275K) +0,60 [0,20(£310K) 
+ 0,80(£490K)] =£382K 


=0,70(£210K) +0,30(£400K) =£267K 
=0,60(£350K) +0,40(£500K)] =£410K 


coste rra utilización 


coste esperado Coin 


coste esperado,,,,,, 


Según la probabilidad y los costes proyectados que 
se han señalado en la Figura 5.6, el coste más bajo espe- 
rado es la opción «compra». 
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Referencia Web 


Se puede encontrar un tutorial excelente sobre el análisis 
del árbol de decisión en 
www.demon.co.uk / mindtool/ dectree.html 


Sin embargo, es importante señalar que se deben con- 
siderar muchos criterios —no sólo el coste — durante 
el proceso de toma de decisiones. La disponibilidad, la 
experiencia del desarrollador/vendedor/contratante, la 
conformidad con los requisitos, la política «local», y la 
probabilidad de cambios son sólo uno de los pocos cri- 
terios que pueden afectar la última decisión para cons- 
truir, volver a utilizar o contratar. 


5.8.2. Subcontratación (outsourcing) 


Más pronto o más tarde toda compañía que desarrolla soft- 
ware de computadora hace una pregunta fundamental: 
«¿Existe alguna forma por la que podamos conseguir a 
bajo precio el software y los sistemas que necesitamos?» 
La respuesta a esta pregunta no es simple, y las discusio- 
nes sobre esta cuestión dan como respuesta una simple 
palabra: subcontratación (outsourcing). 


Referencia Web 
Se puede encontrar información útil (documentos, enlaces) 
acerca del outsourcing en www.outsourcing.com 


El concepto outsourcing es extremadamente simple. 
Las actividades de ingeniería del software se contratan 


Las técnicas de descomposición y los modelos empíri- 
cos de estimación descritos en las secciones anteriores se 
pueden implementar con software. Las herramientas auto- 
máticas de estimación permiten al planificador estimar 
costes y esfuerzos, asícomo llevar a cabo análisis del tipo 
«qué pasa si» con importantes variables del proyecto, 
tales como la fecha de entrega o la selección de perso- 
nal. Aunque existen muchas herramientas automáticas de 
estimación, todas exhiben las mismas características gene- 
rales y todas realizan las seis funciones genéricas mos- 
tradas a continuación[JON98]: 


1. Dimensionamiento de las entregas del proyecto. 
Se estima el «tamaño» de uno o más productos de 
software. Los productos incluyen la representación 
externa del software (por ejemplo, pantallas, Infor- 
mes), el software en sí (por ejemplo, KLDOC), su fun- 
cionalidad (por ejemplo, puntos ge función), y la 
información descriptiva (por ejemplo, documentos). 


Selección de las actividades del proyecto. Se selec- 
ciona el marco de trabajo del proceso adecuado 
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con un tercero, quien hace el trabajo a bajo coste ase- 
gurando una alta calidad. El trabajo de software lleva- 
do dentro de la compañía se reduce a una actividad de 
gestión de contratos. 


outsourcing requiere incluso 
que el desorrollo interno. 


La decisión de contratar fuentes externas puede ser 
estratégica o táctica. En el nivel estratégico, los gesto- 
res tienen en consideración si una parte importante de 
todo el trabajo del software puede ser contratado a otros. 
En el nivel táctico, unjefe de proyecto determina si algu- 
nas partes O todo el proyecto es aconsejable realizarlo 
mediante subcontratación. 

Con independencia de la amplitud del enfoque, la 
decisión de elegir outsourcing es a menudo financiera. 
Un estudio detallado del análisis financiero de la deci- 
sión del outsourcing está fuera del ámbito de este libro 
y se reserva mejor para otros (por ejemplo: [MIN95]). 
Sin embargo, merece la pena realizar un repaso de los 
pros y los contras de la decisión. 


En el lado positivo, los ahorros de coste se pueden 
lograr reduciendo el número de personas y las instala- 
ciones (por ejemplo: computadoras, infraestructura)que 
los apoyan. En el lado negativo, una compañía pierde 
control sobre el software que necesita. Como el soft- 
ware es una tecnología que diferencia sus sistemas, ser- 
vicios, y productos, una compañía corre el riesgo de 
poner su destino en manos de un tercero. 


(Capítulo 2) y se especifica el conjunto de tareas de 
ingeniería del software. 

Predicción de los niveles de la plantilla. Se espe- 
cifica el número de personas disponibles para reali- 
zar el trabajo. Esto es muy importante, puesto que la 
relación entre las personas disponibles y el trabajo 
(esfuerzo previsto) no es muy lineal. 


2 


. Predicción del esfuerzo del software. Las herra- 
mientas de estimación utilizan uno O más modelos 


(por ejemplo, Sección 5.7) que relacionan el tamaño 
de las entregas del proyecto con el esfuerzo necesa- 
rio para producirlas. 

Predicción del coste del software. Dado los resul- 
tados del paso 4, los costes pueden calcularse asig- 
nando proporciones del trabajo a las actividades del 
proyecto señaladas en el paso 2. 

Predicción de la planificación del software. Cuando 
se conoce el esfuerzo, los niveles de la plantilla y las 
actividades del proyecto, se puede realizar un borra- 
dor de la planificación asignando el trabajo a través 

> 


www.elsolucionario.net 


de actividades de ingeniería del software basadas en 
modelos recomendados para la distribución del 
esfuerzo (Capítulo 7). 


Herramientas Case. 


El planificador del proyecto de software tiene que esti- 
rar tres cosas antes de que comience el proyecto: cuán- 
to durará, cuánto esfuerzorequerirá y cuánta gente estará 
implicada. Además, el planificador debe predecir los 
recursos (de hardware y de software) que va a requerir, 
y el riesgo implicado. 

El enunciado del ámbito ayuda a desarrollar estima- 
ciones mediante una o varias de las técnicas siguientes: 
descomposición, modelos empíricos y herramientas 
automáticas. Las técnicas de descomposición requieren 
un esbozo de las principales funciones del software, 
seguido de estimaciones (1) del número de LDC*s, (2) 
de los valores seleccionados dentro del dominio de la 
información, (3) del número de personas-mes requeri- 
das para implementar cada función, o (4)del número 


[BEN92] Bennatan, E. M., Software Project Management: A 
Practitioner's Approach, McGraw-Hill, 1992, 


[BOE31] Boehm, B., Software Engineering Economics, Pren- 
tice-Hall, 1981, 

[BOE89] Boehm, B., Risk Management, IEEE Computer 
Society Press, 1989. 


[BOE96] Boehm, B., «Anchoring the Software Process», IEE 
Software, vol. 13,n.* 4, Julio 1996, pp. 73-82. 


[BOE00] Boehm, B., et al., Software Cost Estimation in 
COCOMOl1I!, Prentice Hall, 2000. 


[BRO75] Brooks, F., The Mythical Man-Month, Addison- 
Wesley, 1975. 


[GAU89] Gause, D. C., y G. M. Weinberg, Exploring Requi- 
rements: Quality Before Design, Dorset House, 1989. 
[HOO91] Hooper, J, W. E., y R. O. Chester, Software Reuse: 

Guidelines and Methods, Plenum Press, 1991. 


[JON96] Jones, C., «How Software Estimation Tools Work», 
American Programmer, vol. 9, 1.27, Julio 1996,pp. 19-27. 
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Cuando se aplican distintas herramientas de esti- 
mación a los mismos datos del proyecto, se observa 
una variación relativamente grande entre los resulta- 
dos estimados. Pero lo que es más importante, a veces 
los valores son bastante diferentes de los valores rea- 
les. Esto refuerza la idea de que los resultados obte- 
nidos por las herramientas de estimación se deben usar 
sólo como «punto de partida» para la obtención de 
estimaciones —no como única fuente para la estima- 
ción—. 


de personas-mes requeridas para cada actividad de inge- 
niería del software. Las técnicas empíricas usan expre- 
siones empíricamente obtenidas para el esfuerzo y para 
el tiempo, con las que se predicen esas magnitudes del 
proyecto. Las herramientas automáticas implementan 
un determinado modelo empírico. 

Para obtener estimaciones exactas para un proyecto, 
generalmente se utilizan al menos dos de las tres técni- 
cas referidas anteriormente. Mediante la comparación 
y la conciliación de las estimaciones obtenidas con las 
diferentes técnicas, el planificador puede obtener una 
estimación más exacta. La estimación del proyecto de 
software nunca será una ciencia exacta, pero la combi- 
nación de buenos datos históricos y de técnicas siste- 
máticas pueden mejorar la precisión de la estimación. 


[MAH96] Mah, M., Quantitive Software Management, Inc., 
private communication. 


[MAT94] Matson, J., B. Barrett y J. Mellichamp, «Software 
Development Cost Estimation Using Function Points», 
IEEE Trans. Software Engineering, vol. 20, n.? 4, Abril 
1994, pp. 275-287. 


[MIN95] Minoli, D., Analizing Outsourcing, McGraw-Hill, 
1995. 


[PHI98] Phillips, D., The Software Project Manager's Hand- 
book, IEEE Computer Society Press, 1998. 


[PUT92] Putnam, L., y W. Myers, Measuresfor Excellence, 
Yourdon Press, 1992. 


[PUT97a] Putnam, L., y W. Myers, «How Solved is the Cost 
Estimation Problem», JEEE Software, Noviembre 1997, 
pp. 105-107. 


[PUT97b] Putnam, L., y W. Myers, Industrial Strength Soft- 
ware: Effective Management Using Measurement, IEEE 
Computer Society Press, 1997. 
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5.1. Suponga que es el gestor de proyectos de una compañía 
que construye software para productos de consumo. Ha con- 
tratado una construcción de software para un sistema de segu- 
ridad del hogar. Escriba una especificación del ámbito que 
describa el software. Asegúrese de que su enunciado del ámbi- 
to sea limitado. Sino está familiarizado con sistemas de segu- 
ridad del hogar, investigue un poco antes de comenzar a 
escribir. Alternativa: sustituya el sistema de seguridad del 
hogar por otro problema que le sea de interés. 

5.2. La complejidad del proyecto de software se trata breve- 
mente en la Sección 5.1. Desarrolle una lista de las caracte- 
rísticas de software (por ejemplo: operación concurrente, salida 
gráfica, etc.), que afecte a la complejidad de un proyecto. Dé 
prioridad a la lista. 

5.3. El rendimiento es una consideración importante durante 
la planificación. Discuta si puede interpretar el rendimiento de 
otra manera, dependiendo del área de aplicación del software. 
5.4. Haga una descomposición de las funciones software 
para el sistema de seguridad del hogar descrita en el Pro- 
blema 5.1. Estime el tamaño de cada función en LDC. Asu- 
miendo que su organización produce 4SOLDC/pm con una 
tarifa laboral de $7.000 por persona-mes, estime el esfuer- 
zo y el coste requerido para construir el software utilizan- 
do la técnica de estimación basada en LDC que se describe 
en la Sección 5.6.3. 

5.5. Utilizando las medidas de punto de función de tres dimen- 
siones que se describe en el Capítulo4, calculeel número de PF 
para el software del sistema de seguridad del hogar, y extraiga las 
estimacionesdel esfuerzo y del coste mediante la técnica de esti- 
mación basada en PF que se describe en la Sección 5,6,4, 

5.6. Utilice el modelo COCOMO II para estimar el esfuerzo 
necesario para construir software para un simple ATM que 
produzca 12pantallas; 10informes, y que necesite aproxima- 


La mayoría de los libros de gestión de proyectos de softwa- 
re contienen estudios sobre la estimación de proyectos. Jones 
(Estimating Software Costs, McGraw Hill, 1998) ha escrito 
el tratado más extenso sobre la estimación de proyectos pu- 
blicado hasta la fecha. Su libro contiene modelos y datos apli- 
cables a la estimación del software en todo el dominio de la 
aplicación. Roetzheim y Beasley (Software Project Cost and 
Schedule Estimating: Best Practices, Prentice-Hall, 1997) 
presentan varios modelos útiles y sugieren las directrices paso 
a paso para generar las estimaciones mejores posibles. 

Los libros de Phillips [PHI98], Bennatan (On Time, Wit- 
hin Budget: Software Project Management Practices and 
Techniques, Wiley, 1995), Whitten (Managing Software Deve- 
lopment Projects: Formulafor Success, Wiley, 1995), Well- 
man (Software Costing, Prentice-Hall, 1992), Londeix (Cost 
Estimationfor Software Development, Addison-Wesley, 1987) 
contienen información útil sobre la planificación y la esti- 
mación de proyectos de software. 

El tratamiento detallado de la estimación del coste de soft- 
ware de Putnam y Myers ([PUT92] y [PUT976b]), y el libro de 
Boehm sobre la economía de la ingenieríadel software([BOES 1] 
y COCOMOlII [BOE00]) describen los modelos de estimación 
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damente 80 componentes de software. Asuma complejidad 
«media» y maduración desarrollador/entorno media. Utilice 
el modelo de composición de aplicación con puntos objeto. 


5.7. Utilice la «ecuación del software» para estimar el soft- 
ware del sistemade seguridad del hogar. Suponga que las Ecua- 
ciones (5.4) son aplicables y que P = 8.000. 


5.8. Compare las estimaciones de esfuerzo obtenidas de los 
Problemas 5.5 y 5.7. Desarrolle una estimación simple para 
el proyecto mediante una estimación de tres puntos. ¿Cuál es 
la desviación estándar?, y ¿cómo afecta a su grado de certeza 
sobre la estimación? 


5.9. Mediante los resultados obtenidos del Problema 5.8, deter- 
mine si es razonable esperar que el resultado se pueda cons- 
truir dentro de los seis meses siguientes y cuántas personas se 
tendrían que utilizar para terminar el trabajo. 


5.10. Desarrolle un modelo de hoja de cálculo que implemente 
una técnica de estimación o más, descritas en el capítulo. Alter- 
nativamente, obtenga uno o más modelos directos para la esti- 
mación desde la web. 


5.11. Para un equipo de proyecto: Desarrolle una herramien- 
ta de software que implemente cada una de las técnicas de esti- 
mación desarrolladas en este capítulo. 


5.12. Parece extraño que las estimaciones de costes y plani- 
ficaciones temporales se desarrollen durante la planificación 
del proyecto de software —antes de haber realizado un aná- 
lisis de requisitos o un diseño detallado —. ¿Por qué cree que 
se hace así? ¿Existen circunstancias en las que no deba pro- 
cederse de esta forma? 


5.13. Vuelva a calcular los valores esperados señalados en el 
árbol de decisión de la Figura 5.6 suponiendo que todas las 
ramas tienen una probabilidad de 50-50. ¿Por qué cambia esto 
su decisión final? 


Ps 


empíricos para la estimación del software. Estos libros propor- 
cionan un análisis detallado de datos que provienen de cientos 
de proyectos de software. Un libro excelente de DeMarco (Con- 
trolling Software Projects, Yourdon Press, 1982) proporciona 
una profunda y valiosa visión de la gestión, medición y esti- 
mación de proyectos de software. Sneed (Software Engineering 
Management, Wiley, 1989) y Macro (Software Engineering : 
Concepts and Management, Prentice —Hall, 1990) estudian la 
estimación del proyecto de software con gran detalle. 

La estimación del coste de líneas de código es el enfoque 
más comúnmente utilizado. Sin embargo, el impacto del para- 
digma orientado a objetos (consulte la Parte Cuarta) puede 
invalidar algunos modelos de estimación. Lorenz y Kidd 
(Object — Oriented Software Metrics, Prentice — Hall, 1994) 
y Cockburn (Surviving Object — Oriented Projects, Addi- 
son— Wesley, 1998 estudian la estimación para sistemas orien- 
tados a objetos. 

En Intemet están disponibles una gran variedad de fuen- 
tes de información sobre la planificación y estimación del 
software. Se puede encontrar una lista actualizada con refe- 
rencias a sitios (páginas) web que son relevantes para la esti- 
mación del software en http://www.pressman5.com. 
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CAPÍTULO 


ANÁLISIS Y GESTIÓN DEL RIESGO 


N su libro sobre análisis y gestión del riesgo, Robert Charette [CHA89] presenta la 
siguiente definición de riesgo: 


En primer lugar, el riesgo afecta a los futuros acontecimientos. El hoy y el ayer están más 
allá de lo que nos pueda preocupar, pues ya estamos cosechando lo que sembramos previamente 
con nuestras acciones del pasado. La pregunta es, podemos, por tanto, cambiando nuestras 
acciones actuales, crear una oportunidad para una situación diferente y, con suerte, mejor para 
nosotros en el futuro. Esto significa, en segundo lugar, que el riesgo implica cambio, que pue- 
de venir dado por cambios de opinión, de acciones, de lugares... [En tercer lugar,] el riesgo 
implica elección, y la incertidumbre que entraña la elección. Por tanto, el riesgo, como la muer- 
te y los impuestos, es una de las pocas cosas inevitables en la vida. 

Cuando se considera el riesgo en el contexto de la ingeniería del software, los tres pilares 
conceptuales de Charette se hacen continuamente evidentes. El futuro es lo que nos preocupa 
—-¿qué riesgos podrían hacer que nuestro proyecto fracasara? —. El cambio es nuestra preocu-= 
pación ¿cómo afectarán los cambios en los requisitos del cliente, en las tecnologías de desa- 
rrollo, en las computadoras a las que va dirigido el proyecto y a todas las entidades relacionadas 
con él, al cumplimiento de la planificación temporal y al éxito en general?. Para terminar, debe- 
mos enfrentarnos a decisiones —¿qué métodos y herramientas deberíamos emplear, cuánta gen- 
te debería estar implicada, cuánta importancia hay que darle a la calidad? —. 


VISTAZO RÁPIDO 


¿Qué es? El análisis y la gestión del ¿Por qué es importante? Pensemos en babilidad y del impacto. Por último, se 


riesgo son una serie de pasos que 
ayudan al equipo del software a com- 
prender y a gestionar la incertidum- 
bre. Un proyecto de software puede 
estar lleno de problemas. Un riesgo 
es un problema potencial — puede 
ocurrir O ng—, Pero sin tener en cuen- 
ta el resultado, realmente es una 
buena idea identificarlo, evaluar su 
probabilidad de aparición, estimar 
su impacto, y establecer un plan de 
contingencia por si ocurre el proble- 
ma. 


¿Quien lo hace? Todos los que estén 


involucrados en el proceso del softwa- 
re - gestores,ingenieros de software y 
clientes — participan en el análisis y 
la gestión del riesgo. 


el lema de los boys scout: «estar prepa- 
rados». El software es una empresa difí- 
cil. Muchas cosas pueden ir mal, y 
francamente, a menudo van mal. Esta es 
la razón para estar preparados -com- 
prendiendo los riesgos y tomando las 
medidas proactivas para evitarlo 0 ges- 
tionarlo— es un elemento clave de una 
buena gestión de proyectosde software. 


¿Cuáles son los pasos? El reconoci- 


miento de que algo puede ir mal es el 
primer paso, llamado identificación del 
riesgo. A continuación, cada riesgo es 
analizado para determinar la probabi- 
lidad de que pueda ocurrir y el daño 
que puede causar si bcurre. Una vez 
establecida esta información, se prio- 
rizan los riesgos, en función de la pro- 


desarrolla un plan para gestionaf 
aquellos riesgos con gran probabilidad 
e impacto. 


¿Cuél es el producto obtenido? Se 


realiza un Plan de Reducción, Super- 
visión y Gestión del Riesgo (RSGR)O 
un informe de riesgos. 


¿Cómo puedo estar seguro de que 


lo he hecho correctamente? Los 
riesgos analizados y gestionados debe- 
rían derivarse del estudio del personal, 
delproducto, del proceso y del proyec- 
to. El RSGR debe serrevisado mientras 
el proyecto se realiza para asegurar 
que los riesgos están siendo controla- 
dos hasta la fecha. Los planes de con- 
tingencia para la gestión del riesgo 
deben ser realistas. 


Peter Drucker [DRU7S5] dijo una vez: «Mientras que es inútil intentar eliminar el riesgo y 
cuestionable el poder minimizarlo, es esencial que los riesgos que se tomen sean los riesgos 
adecuados». Antes de poder identificar los «riesgos adecuados» a tener en cuenta en un pro- 
yecto de software, es importante poder identificar todos los riesgos que sean obvios ajefes de 
proyecto y profesionales del software. 
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Las estrategias se han denominado humorísticamente 
«Escuela de gestión del riesgo de Indiana Jones» 
[THO92]. En las películas, Indiana Jones, cuando se 
enfrentaba a una dificultad insuperable, siempre decía, 
«¡No te preocupes, pensaré en algo!». Nunca se preo- 
cupaba de los problemas hasta que ocurrían, entonces 
Indy reaccionaba de alguna manera heroica. 


Desgraciadamente, el jefe del proyecto de software 
normalmente no es Indiana Jones y los miembros de su 
equipo no son sus fiables colaboradores. Sin embargo, 
la mayoría de los equipos de softwareconfían solamente 
en las estrategias de riesgo reactivas. En el mejor de los 
casos, la estrategia reactiva supervisael proyecto en pre- 
visión de posibles riesgos. Los recursos se ponen apar- 


Aunque ha habido amplios debates sobre la definición 
adecuada para riesgo de software, hay acuerdo común 
en que el riesgo siempre implica dos características 
[HIG95): 


. Incertidumbre: el acontecimiento que caracteriza al 
riesgo puede o no puede ocurrir; por ejemplo, no hay 
riesgos de un 100por 100 de probabilidad". 

+ Pérdida: si el riesgo se convierte en una realidad, 
ocurrirán consecuencias no deseadas o pérdidas. 


Cuando se analizan los riesgos es importante cuan- 
tificar el nivel de incertidumbre y el grado de pérdidas 
asociado con cada riesgo. Para hacerlo, se consideran 
diferentes categorías de riesgos. 


Los riesgos del proyecto amenazan al plan del pro- 
yecto; es decir, si los riesgos del proyecto se hacen rea- 
lidad, es probable que la planificación temporal del 
proyecto se retrase y que los costes aumenten. Los ries- 
gos del proyecto identifican los problemas potenciales de 
presupuesto, planificación temporal, personal (asigna- 


¿Qué tipo de riesgoses problable 
que nos encontremos en el 
software que se construye? 


1 Un riesgo del 100por 100es una limitación del proyecto de soft- 
ware. 
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te, en caso de que pudieran convertirse en problemas 
reales. Pero lo más frecuente es que el equipo de soft- 
ware no haga nada respecto a los riesgos hasta que algo 
va mal. Después el equipo vuela para corregir el pro- 
blema rápidamente. Este es el método denominado a 
menudo «de bomberos». Cuando falla, «la gestión de 
crisis» [CHA 92] entra en acción y el proyecto se encuen- 
tra en peligro real. 

Una estrategia considerablemente más inteligente 
para el control del riesgo es ser proactivo. La estrate- 
gia proactiva empieza mucho antes de que comiencen 
los trabajos técnicos. Se identifican los riesgos poten- 
ciales, se evalúa su probabilidad y su impacto y se 
establece una prioridad según su importancia. Des- 
pués, el equipo de Software establece un plan para 
controlar el riesgo. El primer objetivo es evitar el ries- 
go, pero como no se pueden evitar todos los riesgos, 
el equipo trabaja para desarrollar un plan de contin- 
gencia que le permita responder de una manera efi- 
caz y controlada. A lo largo de lo que queda de este 
capítulo, estudiamos la estrategia proactiva para el 
control de riesgos. 


LIS roda 0 Rai 


ción y organización), recursos, cliente y requisitos y su 
impacto en un proyecto de software. En el Capítulo 5, la 
complejidad del proyecto, tamaño y el grado de incerti- 
dumbre estructural fueron también definidos como fac- 
tores (y estimados) de riesgo del proyecto. 

Los riesgos técnicos amenazan la calidad y la plani- 
ficación temporal del software que hay que producir. Si 
un riesgo técnico se convierte en realidad, la imple- 
mentación puede llegar a ser difícil o imposible. Los 
riesgos técnicos identifican problemas potenciales de 
diseño, implementación, de interfaz, verificación y de 
mantenimiento. Además, las ambigitedades de especi- 
ficaciones, incertidumbre técnica, técnicas anticuadas 
y las «tecnologías punta» son también factores de ries- 
go. Los riesgos técnicos ocurren porque el problema es 
más difícil de resolver de lo que pensábamos. 

Los riesgos del negocio amenazan la viabilidad del 
software a construir. Los riesgos del negocio a menudo 
ponen en peligro el proyecto o el producto. Los candi- 
datos para los cinco principales riesgos del negocio son: 
(1) construir un producto o sistema excelente que no 
quiere nadie en realidad (riesgo de mercado); (2) cons- 
truir un producto que no encaja en la estrategia comer- 
cial general de la compañía (riesgo estratégico); (3) 
construir un producto que el departamento de ventas no 
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sabe cómo vender; (4)perder el apoyo de una gestión 
experta debido a cambios de enfoque O a cambios de 
personal (riesgo de dirección); (5 )perder presupuesto 
opersonal asignado (riesgos de presupuesto). Es extre- 
madamente importante recalcar que no siempre fun- 
ciona una categorización tan sencilla. Algunos riesgos 
son simplemente imposibles de predecir. 


se permite el lujo de conocer tan 
no contenga ninguna sorpresa, y 
con riesgo. 

Y. 


cariuLo o ANÁLISIS Y GESTIÓN DEL RIESGO 


Otra categorización general de los riesgos ha sido pro- 
puesta por Charette [CHA89]. Los riesgos conocidos son 
todos aquellos que se pueden descubrir después de una 
cuidadosa evaluación del plan del proyecto, del entorno 
técnico y comercial en el que se desarrolla el proyecto y 
otras fuentes de información fiables (por ejemplo: fechas 
de entregapoco realistas, falta de especificación de requi- 
sitos o de ámbito del software, o un entorno pobre de 
desarrollo). Los riesgos predecibles se extrapolan de la 
experiencia en proyectos anteriores (por ejemplo: cam- 
bio de personal, mala comunicación con el cliente, dis- 
minución del esfuerzo del personal a medida que atienden 
peticiones de mantenimiento). Los riesgos impredecibles 
son el comodín de la baraja. Pueden ocurrir, pero son 
extremadamente difíciles de identificarpor adelantado. 


La identificación del riesgo es un intento sistemáti- 
co para especificar las amenazas al plan del proyecto 
(estimaciones, planificación temporal, carga de recur- 
sos, etc.). Identificando los riesgos conocidos y prede- 
cibles, el gestor del proyecto da un paso adelante para 
evitarlos cuando sea posible y controlarlos cuando sea 
necesario. 


Consofh 


Aunque los riesgos genéricos son importantes ar tener en 
cuento, habitualmente los riesgos específicos del producto 
provocan lo mayoría de los dolores de cabeza. Esté 
convencido al invertir el tiempo en identificar tantos 
riesgos específicos de/ producto como seo posible. 


Existen dos tipos diferenciados de riesgos para cada 
categoría presentada en la Sección 6.2: riesgos genéri- 
cos y riesgos específicos del producto. Los riesgos gené- 
ricos son una amenaza potencial para todos los proyectos 
de software. Los riesgos específicos de producto sólo 
los pueden identificar los que tienen una clara visión de 
la tecnología, el personal y el entorno específico del pro- 
yecto en cuestión. Para identificar los riesgos específi- 
cos del producto, se examinan el plan del proyecto y la 
declaración del ámbito del software y se desarrolla una 
respuesta a la siguiente pregunta: «¿Qué características 
especiales de este producto pueden estar amenazadas 
por nuestro plan del proyecto?» 

Un método para identificar riesgos es crear una lis- 
ta de comprobación de elementos de riesgo. La lista 
de comprobación se puede utilizar para identificar ries- 
gos y se centra en un subconjunto de riesgos conoci- 
dos y predecibles en las siguientes subcategorías 
genéricas: 


. Tamaño del producto: riesgos asociados con el tamaño 
general del software a construir o a modificar. 


» Impacto en el negocio: riesgos asociados con las limi- 
taciones impuestas por la gestión o por el mercado. 

. Características del cliente: riesgos asociados con la 
sofisticación del cliente y la habilidad del desarro- 
llador para comunicarse con el cliente en los momen- 
tos oportunos. 

. Definición del proceso: riesgos asociados con el 
grado de definición del proceso del software y su 
seguimiento por la organización de desarrollo. 

+. Entorno de desarrollo: riesgos asociados con la dis- 
ponibilidad y calidad de las herramientas que se van 
a emplear en la construcción del producto. 

» Tecnologíaa construir: riesgos asociados con la com- 
plejidad del sistema a construir y la tecnología punta 
que contiene el sistema. 

« Tamañoy experiencia de la plantilla: riesgos asocia- 
dos con la experiencia técnica y de proyectos de los 
ingenieros del software que van a realizar el trabajo. 


lista de comprobación de elementos del riesgo. 


La lista de comprobación de elementos de riesgo pue- 
de organizarse de diferentes maneras. Se pueden res- 
ponder a cuestiones relevantes de cada uno de los temas 
apuntados anteriormente para cada proyecto de soft- 
ware. Las respuestas a estas preguntas permiten al pla- 
nificador del proyecto estimar el impacto del riesgo. Un 
formato diferente de lista de comprobación de elemen- 
tos de riesgo contiene simplemente las características 


relevantes para cada subcategoría genérica. Finalmen- 


te, se lista un conjunto de «componentes y controlado- 


res del riesgo» [AFC88] junto con sus probabilidades 
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de aparición. Los controladores del rendimiento, el 
soporte, el coste y la planificación temporal del proyecto 
se estudian como respuesta a preguntas posteriores. 

Se ha propuesto un gran numero de listas de com- 
probación para el riesgo del proyecto de software en los 
textos (por ejemplo, [SEI93], [KAR96])). Estos propor- 
cionan una visión útil de riesgos genéricos para pro- 
yectos de software y deberían utilizarse cada vez que 
se realice el análisis y la gestión del riesgo. Sin embar- 
go, se puede utilizar una lista de preguntas relativamente 
pequeña para proporcionar una indicación preliminar 
de cuando un proyecto es «arriesgado». 


siesgo es gestión de proyectos pora 


6.3.1. Evaluación Global del Riesgo del Proyecto 


Las siguientes preguntas provienen de los datos del ries- 
go obtenidos mediante las encuestas realizadas a ges- 


CATEGORÍA _ 


CATASTRÓFICA 
CRITICA 


RENDIMIENTO SOPORTE 


El software no 
responde o no 
admite soporte 


Degradación 
significativa para 
noalcanzar 

el rendimiento técnico 


el rendimiento del sistema hasta donde 
el éxito de la misión es cuestionable 


Alguna reducción 
en el rendimiento 
técnico de software 

la degradación de la misión secundaria 


De mínima a pequeña | El soporte 
reducción en el del software 
rendimiento técnico responde 


MARGINAL 


Dejar de cumplir los requisitos provocaría 
inconvenientes o impactos no operativos 


Software fácil 
de dar soporte 


No hay reducción 
en el rendimiento 
técnico 


Dejar de cumplir los requisitos degradaría 


Pequeños retrasos 
en modificaciones 


Dejar de cumplir los requisitos provocaría 


tores de proyectos de software expertos de diferentes 
partes del mundo [KEI98]. Las preguntas están orde- 
nadas por su importancia relativa para el éxito de un 
proyecto. 


* ¿Corre un riesgo grave el proyecto de 
software en el que estamos trabajando? 


1.¿Se han entregado los gestores del software 
y clientes formalmente para dar soporte al pro- 
yecto? 


2. ¿Están completamente entusiasmados los usuarios 
finales con el proyecto y con el sistema/producto a 
construir? 


3. ¿Han comprendido el equipo de ingenieros de soft- 
ware y los clientes todos los requisitos? 


4.¿Han estado los clientes involucrados por completo 
en la definición de los requisitos? 


5. ¿Tienen los usuarios finales expectativas realistas? 


6. ¿Es estable el ámbito del proyecto? 


PLANIFICACIÓN 
TEMPORAL 


Dejar de cumplir los requisitos provocaría Malos resultados en un aumento de costes y retrasos de la 
el fallo de la misión planificación temporal con gastos que superan las £500.00( 


Fecha 
de entrega 
inalcanzable 


Recortes financieros 
significativos, presupuestos 
excedidos 


Malos resultados en retrasos operativos y/o 
aumento de coste con un valor esperado 
de €100.000a £500.000 
Algunos recortes de los 
recursos financieros, posibles 
excesos del presupuesto 


Posibles retrasos 
en la fecha de entrega 


Los costes, impactos y/o retrasosrecuperables 
de la planificación temporal con un valor estimado 
de £1.000 a £100.000 


Recursos 
financieros suficientes 


Planificacióntemporal 
realista, alcanzable 


Los errores provocan impactos mínimos en el coste y/o 
planificación temporal con un valor esperado de menos 
de £1.000 


Posible superávit 
de presupuesto 


Fecha de entrega 
fácilmente alcanzable 


Nota :(1) Posiblesconsecuencias de errores o defectos del software no detectados. 
(2) Posibles consecuencias si el resultado deseado no se consigue. 


FIGURA 6.2. Evaluación del impacto [BOE891. 
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7. ¿Tiene el ingeniero de software el conjunto ade- 
cuado de habilidades? 


8. ¿Son estables los requisitos del proyecto? 


9. ¿Tiene experiencia el equipo del proyecto con la 
tecnología a implementar? 


10.¿Es adecuado el número de personas del equipo del 
proyecto para realizar el trabajo? 


11. ¿Están de acuerdo todos los clientes/usuarios en la 
importanciadel proyecto y en los requisitos del sis- 
tema/producto a construir? 


Referencia 


«Un radar del riesgo)) es una base de datos de gestión de 
riesgo que ayuda a los gestores del proyecto a identificar, 
priorizar y comunicar los riesgos del proyecto. Se puede 
encontrar en www.spmn.com/rsktrkr.html 


6.3.2. Componentes y controladores del riesgo 


Las Fuerzas Aéreas de Estados Unidos [AFC88] han 
redactado un documento que contiene excelentes direc- 
trices para identificar riesgos del software y evitarlos. 
El enfoque de las Fuerzas Aéreas requiere que el ges- 
tor del proyecto identifique los controladores del ries- 
go que afectan a los componentes de riesgo del software 
—rendimiento, coste, soporte y planificación tempo- 
ral— En el contexto de este estudio, los componentes 
de riesgo se definen de la siguiente manera: 


+ riesgo de rendimiento: el grado de incertidumbrecon 

el que el producto encontrará sus requisitos y se ade- 

cue para su empleo pretendido; 

riesgo de coste: el grado de incertidumbre que man- 

tendrá el presupuesto del proyecto; 

+ riesgo de soporte: el grado de incertidumbre de la 
facilidad del software para corregirse, adaptarse y 
ser mejorado; 


CAPITULO 6 ANÁLISIS Y GESTIÓN DEL RIESGO 


riesgo de laplanificación temporal: el grado de incer- 
tidumbre con que se podrá mantener la planificación 
temporal y de que el producto se entregue a tiempo. 


El impacto de cada controlador del riesgo en el com- 
ponente de riesgo se divide en cuatro categorías de impac- 
to — despreciable, marginal, crítico y catastrófico —. 
Como muestra la Figura 6.1 [BOE89], se describe una 
caracterizaciónde las consecuenciaspotenciales de erro- 
res (filas etiquetadas con 1) o la imposibilidad de conse- 
guir el producto deseado (filas etiquetadas con 2). La 
categoría de impacto es elegida basándose en la caracte- 
rización que mejor encaja con la descripción de la tabla. 


robabilidac 


La estimación del tamaño puedi 
ser significativamente baja 


ayor número de usuarios 
de los previstos 


enos reutilización 
de la prevista 


Los usuariosfinales 
se resisten al sistema 


La fecha de entrega estará 
muy ajustada 


Se perderán los presupuestos 


El cliente cambiará 
los requisitos 


Latecnología no alcanzará 
las espectativas 


Falta de formación 
en las herramientas 


Personalsin experiencia 


Habrá muchoscambios 
de personal 


Valores de impacto : 
1- catastrófico 2 -crítico 
3 - marginal 4 - despreciable 
FIGURA 6.2. Ejemplo de una tabla de riesgo antes 
de la clasificación. 


Laproyección del riesgo, también denominada estima- 
ción del riesgo, intenta medir cada riesgo de dos mane- 
ras —la probabilidad de que el riesgo sea real y las 
consecuencias de los problemas asociados con el ries- 
go, si ocurriera —. Eljefe del proyecto, junto con otros 
gestores y personal técnico, realiza cuatro actividades 
de proyección del riesgo [1]: (1) establecer una escala 
que refleje la probabilidad percibida del riesgo; (2) defi- 
nir las consecuencias del riesgo; (3) estimar el impacto 
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del riesgo en el proyecto y en el producto, y (4)apun- 
tar la exactitud general de la proyección del riesgo de 
manera que no haya confusiones. 


6.4.1. Desarrollo de una tabla de riesgo 


Una tabla de riesgo le proporciona aljefe del proyecto una 
sencillatécnica para la proyección del riesgo'. En la Figu- 
ra 6.2 se ilustra una tabla de riesgo como ejemplo. 


2 La tabla de riesgo debería implementarse como un modelo de hoja 
de cálculo. Esto permite un fácil manejo y ordenación de las entra- 
das. 
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Un equipo de proyecto empieza por listar todos los 
riesgos (no importa lo remotos que sean) en la primera 
columna de la tabla. Se puede hacer con la ayuda de la 
lista de comprobación de elementos de riesgo presen- 
tada en la Sección 6.3. Cada riesgo es categorizado en 
la segunda columna (por ejemplo: PS implica un ries- 
go del tamaño del proyecto, BU implica un riesgo de 
negocio). La probabilidad de aparición de cada riesgo 
se introduceen la siguiente columna de la tabla. El valor 
de la probabilidad de cada riesgo puede estimarse por 
cada miembro del equipo individualmente. Se sondea 
a los miembros del equipo individualmente de un modo 
rotativo (round-robin) hasta que comience a converger 
su evaluación sobre la probabilidad del riesgo. 


Impacto 


Factor 
de riesgo 


despreciable Alto 


— 
Relevancia 
para 
la gestión 


Muy bajo 


Probabilidadl 
de que ocurra 


FIGURA 6.3. Riesgos y relevancia para la gestión. 


A continuación se valora el impacto de cada riesgo. 
Cada componente de riesgo se valora usando la carac- 
terización presentada en la Figura 6.1, y se determina 
una categoría de impacto. Las categorías para cada uno 
de los cuatro componentes de riesgo — rendimiento, 
soporte, coste y planificación temporal — son prome- 
diados* para determinar un valor general de impacto. 


loop 


Plense seriamente en el software que está construyendo 
y pregúnteseg si mismo «¿Qué puede ir mal?» Creesu 
propio listo y consultea otros miembros del equipo de 
software para hacer lo mismo. 


3 Puede usarse una media ponderada si un componente de riesgo 
tiene más influencia en el proyecto. 
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Una vez que se han completado las cuatro primeras 
columnas de la tabla de riesgo, la tabla es ordenada por 
probabilidad y por impacto. Los riesgos de alta proba- 
bilidad y de alto impacto pasan a lo alto de la tabla, y 
los riesgos de baja probabilidad caen a la parte de aba- 
jo. Esto consigue una priorización del riesgo de primer 
orden. 

Eljefe del proyecto estudia la tabla ordenada resul- 
tante y define una línea de corte. La Eínea de corte (dibu- 
jada horizontalmentedesde un punto en la tabla) implica 
que sólo a los riesgos que quedan por encima de la línea 
se les prestará atención en adelante. Los riesgos que 
caen por debajo de la línea son reevaluados para con- 
seguir una priorización de segundo orden. Como mues- 
tra la Figura 6.3, el impacto del riesgo y la probabilidad 
tienen diferente influencia en la gestión. Un factor de 
riesgo que tenga un gran impacto pero muy poca pro- 
babilidad de que ocurra no debería absorber una canti- 
dad significativade tiempo de gestión. Sin embargo, los 
riesgos de gran impacto con una probabilidad moderada 
a alta y los riesgos de poco impacto pero de gran pro- 
babilidad deberían tenerse en cuenta en los procedi- 
mientos de análisis de riesgos que se estudian a conti- 


nuación. 
e S 
Y VE 


l atabla de riesgos está ordenada por probabilidad 
y por el impacto para asignar una prioridad a los riesgos. 


Todos los riesgos que se encuentran por encima de 
la línea de corte deben ser considerados. La columna 
etiquetada RSGR* contiene una referencia que apunta 
hacia un Plan de reducción, supervisión y gestión del 
riesgo, O alternativamente, a un informe del riesgo desa- 
rrollado para todos los riesgos que se encuentran por 
encima de la línea de corte. El plan RSGR y el informe 
del riesgo se estudian en la Sección 6.5. 


'preporación está preparando fallar. 


La probabilidad de riesgo puede determinarse hacien- 
do estimaciones individuales y desarrollando después 
un único valor de consenso. Aunque este enfoque es fac- 
tible, se han desarrollado técnicas más sofisticadas para 
determinar la probabilidad de riesgo [AFC88]. Los con- 
troladores de riesgo pueden valorarse en una escala de 
probabilidad cualitativa que tiene los siguientes valo- 
res: imposible, improbable, probable y frecuente. Des- 
pués puede asociarse una probabilidad matemática con 


* En inglés RMMM (Risk Mitigation, Monitoring and Management). 


www.elsolucionario.net 


cada valor cualitativo (por ejemplo: una probabilidad 
del 0.7 al 1,0 implica un riesgo muy probable). 


6.4.2. Evaluación del impacto del riesgo 


Tres factores afectan a las consecuencias probables de 
un riesgo si ocurre: su naturaleza, su alcance y cuando 
ocurre. La naturaleza del riesgo indica los problemas 
probables que aparecerán si ocurre. Por ejemplo, una 
interfaz externa mal definida para el hardware del clien- 
te (unriesgo técnico) impedirá un diseño y pruebas tem- 
pranas y probablemente lleve a problemas de integración 
más adelante en el proyecto. El alcance de un riesgo 
combina la severidad (¿cómo de serio es el problema?) 
con su distribución general (¿qué proporción del pro- 
yecto se verá afectado y cuantos clientes se verán per- 
judicados?). Finalmente, la temporización de un riesgo 
considera cuándo y por cuánto tiempo se dejará sentir 
el impacto. En la mayoría de los casos, un jefe de pro- 
yecto prefiere las «malas noticias» cuanto antes, pero 
en algunos casos, cuanto más tarden, mejor. 
Volviendo una vez más al enfoque del análisis de 
riesgo propuesto por las Fuerzas Aéreas de Estados Uni- 
dos [AFC88], se recomiendan los siguientes pasos para 
determinar las consecuencias generales de un riesgo: 


1, Determinar la probabilidad media de que ocurra un 


valor para cada componente de riesgo. 
. Empleando la Figura 6.1, determinar el impacto de 
cada componente basándose en los criterios mos- 
trados. 
Completar la tabla de riesgo y analizar los resulta- 
dos como se describe en las secciones precedentes. 


¿Cómo evaluamos las 
* consecuencias de un riesgo? 


La exposición al riesgo en general, ER, se determi- 
na utilizando la siguiente relación [HAL98] : 


ER=PxC 


donde P es la probabilidad de que ocurra un riesgo, y 
C es el coste del proyecto si el riesgo ocurriera. 


Por ejemplo, supongamos que el equipo del pro- 
yecto define un riesgo para el proyecto de la siguien- 
te manera: 


Identificación del riesgo :Solo el 70 por 100de 
los componentes del software planificados para reu- 
tilizarlos pueden, de hecho, integrarse en la aplica- 
ción. La funcionalidad restante tendrá que ser 
desarrollada de un modo personalizado. 


Probabilidad del riesgo :80por 100 (probable). 


Impacto del riesgo :60 componentesde software 
reutilizables fueron planificados. Si solo el 70 por 
100 pueden usarse, 18 componentes tendrán que 
desarrollarse improvisadamente (además de otro soft- 
ware personalizado que ha sido planificado para su 
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desarrollo). Puesto que la media por componente es 
de 100 LDC y los datos locales indican que el cos- 
te de la ingeniería del software para cada LDC es de 
£14,00; el coste global (impacto) para el desarrollo 
de componentes sería 18x 100x 14=225.200 


Exposición al riesgo :ER = 0,80 x 25.200 ” 
220.200 


La exposición al riesgo se puede calcular para cada 
riesgo en la tabla de riesgos, una vez que se ha hecho 
una estimación del coste del riesgo. La exposición al 
riesgo total para todos los riesgos (sobre la línea de cor- 
te en la tabla de riesgos) puede proporcionar un signifi- 
cado para ajustar el coste final estimado para un proyecto. 
También puede ser usado para predecir el incremento 
probable de recursos de plantilla necesarios para varios 
puntos durante la planificación del proyecto. 

La proyección del riesgo y las técnicas de análisis 
descritas en las Secciones 6.4.1 y 6.4.2 se aplican rei- 
teradamente a medida que progresa el proyecto de soft- 
ware. El equipo del proyecto debería volver a la tabla 
de riesgos a intervalos regulares, volver a evaluar cada 
riesgo para determinar qué nuevas circunstancias hayan: 
podido cambiar su impacto o probabilidad. Como con- 
secuencia de esta actividad, puede ser necesario añadir 
nuevos riesgos a la tabla, quitar algunos que ya no sean 
relevantes y cambiar la posición relativa de otros. 


Cons) 


Compare lo ER poro todos los riesgos con el coste estimado 
del proyecto. Silo ER es superioral 50 por 100 del coste 
del proyecto, se deberú evaluar lo viabilidad del proyecta. 


6.4.3. Evaluación del riesgo 


En este punto del proceso de gestión del riesgo, hemos 
establecido un conjunto de temas de la forma [CHA89]: 


l. x.] 


[r 131 


ia 
donde r, es el riesgo, 1; es la probabilidad del riesgo y 
x, es el impacto del riesgo. Durante la evaluación del 
riesgo, se sigue examinando la exactitud de las estima- 
ciones que fueron hechas durante la proyección del ries- 
go, se intenta dar prioridades a los riesgos que no se 
habían cubierto y se empieza a pensar las maneras de 
controlar y/o impedir los riesgos que sea más probable 
que aparezcan. 

Para que sea útil la evaluación, se debe definir un nivel 
de referencia de riesgo [CHA89]. Para la mayoría de los 
proyectos, los componentes de riesgo estudiados ante- 
riormente —rendimiento,coste, soporte y planificación 
temporal — también representan niveles de referencia 
de riesgos. Es decir, hay un nivel para la degradación del 
rendimiento, exceso de coste, dificultades de soporte o 
retrasos de la planificación temporal (o cualquier com- 
binación de los cuatro) que provoquen que se termine el 
proyecto. Si una combinación de riesgos crea problemas 
de manera que uno o más de estos niveles de referencia 
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se excedan, se parará el trabajo. En el contexto del aná- 
lisis de riesgos del software, un nivel de referencia de 
riesgo tiene un solo punto, denominado punto de refe- 
rencia O punto de ruptura, en el que la decisión de seguir 
con el proyecto o dejarlo (los problemas son demasiado 
graves) son igualmente aceptables. La Figura 6.4 repre- 
senta esta situación gráficamente. 


a 

ne 

o 

== Punto de referencia (valor : 
3 . 

2 del coste, valor del tiempo) 
pa 

2 

o Tendrá lugar el abandono 
2 del proyecto 


Exceso de la planif 


Exceso en el coste previsto 


FIGURA 6.4. Nivel de referencia de riesgo. 


9] 
a 


CLAVE 


Bnivel de referencia del riesgo establece su tolerancia para 
el sufrimiento. Una vez que la exposición al riesgo supera el 
nivel de referencia, el proyecto puede ser terminodo. 


En realidad, el nivel de referencia puede raramente 
representarse como una línea nítida en el gráfico. En la 
mayoría de los casos es una región en la que hay áreas 
de incertidumbre, es decir, intentar predecir una deci- 
sión de gestión basándose en la combinación de valo- 
res de referencia es a menudo imposible. Por tanto, 
durante la evaluación del riesgo, se realizan los siguien- 
tes pasos: 


1. Definir los niveles de referencia de riesgo para el 
proyecto; 

2. Intentar desarrollar una relación entre cada (r; E l, x;) 
y cada uno de los niveles de referencia; 

. Predecirel conjunto de puntos de referencia que defi- 
nan la región de abandono, limitado por una curva o 


áreas de incertidumbre; 


. Intentar predecir como afectarán las combinaciones 
compuestas de riesgos a un nivel de referencia. 


Es mejor dejar un estudio más detallado para libros 
especializados en el análisis de riesgos (por ejemplo: 


[CHA89], [ROW88]). 


Durante las primeras etapas de la planificación del 
proyecto, un riesgo puede ser declarado de un modo muy 
general. Con el paso del tiempo y con el aprendizaje 
sobre el proyecto y sobre el riesgo, es posible refinar el 
riesgo en un conjunto de riesgos más detallados, cada 
uno algo más fácil de reducir, supervisar y gestionar. 


$ ¿Cuál es una buena forma 
de describir un riesgo? 

Una forma de hacer esto es presentar el riesgo de 
la forma condición-transición-consecuencia(CTC) 
[GLU94]. Es decir, el riesgo se presenta de la siguien- 
te forma: 


Dada esta <condición> entonces existe preocupación 
por (posiblemente) <consecuencia>. 


Utilizando el formato CTC para volver a utilizar el ries- 
go presentado en la Sección 6.4.2, podemos escribir: 

Dado que todos los componentesreutilizablesdel soft- 
ware deben ajustarse a los estándares específicos del dise- 
ño y que algunos no lo hacen, es entonces preocupante 
que (posiblemente) solo el 70por 100 de los módulos 
planificados para reutilizar puedan realmente integrarse 
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en el sistema que se está construyendo, teniendo como 
resultado la necesidad de que el ingeniero tenga que cons- 
truir el 30 por 100 de los componentes restantes. 

La condición general que acabamos de destacar pue- 
de ser refinada de la siguiente manera: 


Subcondición 1: Ciertos componentes reutiliza- 
bles fueron desarrollados por terceras personas sin el 
conocimiento de los estándares internos de diseño. 


Subcondición 2: El estándar de diseño para inter- 
faces de componentes no ha sido asentado y puede 
no ajustarse a ciertos componentes reutilizables exis- 
tentes. 


Subcondición 3: Ciertos componentes reutiliza- 
bles han sido implementados en un lenguaje no 
soportado por el entorno para el que el sistema ha 
sido construido. 


Las consecuencias relacionadas con estas subcondi- 
ciones refinadas siguen siendo las mismas (por ejemplo, 
el 30por 100de los componentes del software deben ser 
construidos de un modo personalizado), pero el refina- 
miento ayudaa aislar los riesgos señalados y puede con- 
ducir a un análisis y respuesta más sencilla. 
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Todas las actividades de análisis de riesgo presentadas 
hasta ahora tienen un solo objetivo — ayudar al equipo 
del proyecto a desarrollar una estrategia para tratar los 
riesgos —. Una estrategia eficaz debe considerar tres 
aspectos: 


+ Evitar el riesgo. 


+ Supervisarel riesgo, y 
+ Gestionarel riesgo y planes de contingencia. 


fontos precauciones, es paro no dejor 


Si un equipo de software adopta un enfoque proac- 
tivo frente al riesgo, evitarlo es siempre la mejor estra- 
tegia. Esto se consigue desarrollando un plan de 
reducción del riesgo. Por ejemplo, asuma que se ha 
detectado mucha movilidad de la plantilla como un ries- 
go del proyecto, r; Basándose en casos anteriores y en 
la intuición de gestión, la probabilidad, /;, de mucha 
movilidad se estima en un 0,70 (70 por 100, bastante 
alto) y el impacto, x,, está previsto en el nivel 2. Esto 
es, un gran cambio puede tener un impacto crítico en el 
coste y planificación temporal del proyecto. 

Para reducir el riesgo, la gestión del proyecto debe 
desarrollar una estrategia para reducir la movilidad. 
Entre los pasos que se pueden tomar: 


Reunirse con la plantilla actual y determinar las causas 
de la movilidad (por ejemplo: malas condiciones de tra- 
bajo, salarios bajos, mercado laboral competitivo). 


Actuar para reducir esas causas que estén al alcance 
de nuestro control antes de que comience el proyecto. 


Una vez que comienza el proyecto, asumir que habrá 
movilidad y desarrollartécnicas que aseguren la con- 
tinuidad cuando se vaya la gente. 


Organizar los equipos del proyecto de manera que 
la información sobre cada actividad de desarrollo 
esté ampliamente dispersa. 


Definir estándares de documentación y establecer 
mecanismos para estar seguro de que los documen- 
tos se cumplimentan puntualmente. 


Referencia 


Se puede obtener uno excelente CPF (cuestiones que 
se preguntan frecuentemente) en 
www.sei.cmu.edu / organization /programs / 
sepm/risk/risk.faq.html 


A medida que progresa el proyecto, comienzan las 
actividades de supervisión del riesgo. El jefe del pro- 
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yecto supervisa factores que pueden proporcionar una 
indicación sobre si el riesgo se está haciendo más o 
menos probable. En el caso de gran movilidad del per- 
sonal, se pueden supervisar los siguientes factores: 


Actitud general de los miembros del equipo basán- 
dose en las presiones del proyecto; 
Grado de compenetración del equipo; 


Relaciones interpersonales entre los miembros del 
equipo; 

Problemas potenciales con compensaciones y bene- 
ficios; 

Disponibilidad de empleo dentro y fuera de la com- 
pañía. 


pora un evento imprevisto 


Además de supervisar los factores apuntados ante- 
riormente, el jefe del proyecto debería supervisar tam- 
bién la efectividad de los pasos de reducción del riesgo. 
Por ejemplo, un paso de reducción de riesgo apuntado 
anteriormente instaba a la definición de «estándares de 
documentación y mecanismos para asegurarse de que 
los documentos se cumplimenten puntualmente». Éste 
es un mecanismo para asegurarse la continuidad, en caso 
de que un individuo crítico abandone el proyecto. El 
jefe del proyecto debería comprobar los documentos 
cuidadosamente para asegurarse de que son válidos y 
de que cada uno contiene la información necesaria en 
caso de que un miembro nuevo se viera obligado a unir- 
se al equipo de software a mitad del proyecto. 

La gestión del riesgo y los planes de contingencia 
asumen que los esfuerzos de reducción han fracasado y 
que el riesgo se haconvertido en una realidad. Conti- 
nuando con el ejemplo, el proyecto va muy retrasado y 
un número de personas anuncia que se va. Si se ha segui- 
do la estrategia de reducción, tendremos copias de segu- 
ridad disponibles, la información está documentada y 
el conocimiento del proyecto se ha dispersado por todo 
el equipo. Además, el jefe del proyecto puede tempo- 
ralmente volver a reasignar los recursos (y reajustar la 
planificación temporal del proyecto) desde las funcio- 
nes que tienen todo su personal, permitiendo a los recién 
llegados que deben unirse al equipo que vayan «cogien- 
do el ritmo». A los individuos que se van se les pide que 
dejen lo que estén haciendo y dediquen sus últimas 
semanas a «transferir sus conocimientos». Esto podría 
incluir la adquisición de conocimientos por medio de 
vídeos, el desarrollo de «documentos con comentarios» 
y/o reuniones con otros miembros del equipo que per- 
manezcan en el proyecto. 
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ConsuoHh 


Siel valor poro un riesgo específico es menor que el coste 
de lo reducción de/riesgo, no trate de reducirel riesgo 
pero continúe supervisándolo. 


Es importante advertir que los pasos RSGR provo- 
can aumentos del coste del proyecto. Por ejemplo, 
emplear tiempo en conseguir «tun reserva» de cada téc- 
nico crítico cuesta dinero. Parte de la gestión de riesgos 
es evaluar cuando los beneficios obtenidos por los pasos 
RSGR superan los costes asociados con su implemen- 
tación. En esencia, quien planifique el proyecto realiza 
el clásico análisis coste/beneficio. Si los procedimien- 
tos para evitar el riesgo de gran movilidad aumentan el 
coste y duración del proyecto aproximadamente en un 

15 por 100, pero el factor coste principal es la «copia 
de seguridad», el gestor puede decidir no implementar 
este paso. Por otra parte si los pasos para evitar el ries- 
go llevan a una proyección de un aumento de costes del 


3 por 100 y de la duración en un 3 por 100, la gestión 
probablemente lo haga. 

Para un proyecto grande se pueden identificar unos 
30 6 40 riesgos. Si se pueden identificar entre tres y 
siete pasos de gestión de riesgo para cada uno, ¡la ges- 
tión del riesgo puede convertirse en un proyecto por 
sí misma! Por este motivo, adaptamos la regla de Pare- 
to 80/20 al riesgo del software. La experiencia dice 
que el 80 por 100del riesgo total de un proyecto (por 
ejemplo: el 80 por 100 de la probabilidad de fracaso 
del proyecto) se debe solamente al 20 por 100 de los 
riesgos identificados. El trabajo realizado durante pro- 
cesos de análisis de riesgo anteriores ayudará al jefe 
de proyecto a determinar qué riesgos pertenecen a ese 
20 por 100 (por ejemplo, riesgos que conducen a una 
exposición al riesgo alta). Por este motivo, algunos 
de los riesgos identificados, valorados y previstos pue- 
den no pasar por el plan RSGR —no pertenecen al 20 
por 100 crítico — (los riesgos con la mayor prioridad 
del proyecto). 


El riesgo no se limita al proyecto de software solamente. 
Pueden aparecer riesgos después de haber desarrollado 
con éxito el software y de haberlo entregado al cliente. 
Estos riesgos están típicamente asociados con las conse- 
cuencias del fallo del software una vez en el mercado. 

En los comienzos de la informática, había un recha- 
zo al uso de las computadoras (y del software) para el 
control de procesos críticos de seguridad como por ejem- 
plo reactores nucleares, control de vuelos de aviones, 
sistemas de armamento y grandes procesos industria- 
les. Aunque la probabilidad de fallo de un sistema de 
alta ingeniería es pequeña, un defecto no detectado en 
un sistema de control y supervisión basados en com- 
putadora podría provocar unas pérdidas económicas 
enormes o, peor, daños físicos significativos O pérdida 
de vidas humanas. Pero el coste y beneficios funciona- 
les del control y supervisión basados en computadora a 
menudo superan al riesgo. Hoy en día, se emplean regu- 
larmente hardware y software para el control de siste- 
mas de seguridad crítica. 

Cuando se emplea software como parte de un siste- 
ma de control, la complejidadpuede aumentar del orden 
de una magnitud o más. Defectos sutiles de diseño indu- 
cidos por error humano —algo que puede descubrirse 
y eliminarse con controles convencionales basados en 
hardware — se convierten en mucho más difíciles de 
descubrir cuando se emplea software. 


Se puede encontrar una gran base de datos con todos las 
entradas del Foro ACM sobre riesgos en 
catless.ncl.ac.uk /Risks /search.html 


Hoja de información de riesgo 


ld. Riesgo: P02-4-32 | fecha: 5/9/02 | Probabilidad: 80% | Impacto: alto 


Descripción : 

Sólo el 70 por 100de los componentes del software planificados 
para reutilizar pueden, de hecho, integrarse en la aplicación. 

E funcionalidad restante tendrá que desarrollarse 

Je un modo personalizado. 


Refinamiento/contexto: 

Subcondición 1: Ciertos componentes reutilizables fueron desarrollados 
por terceras personas sin el conocimiento 
de los estandares internos de diseño. 


Subcondición 2: Elestándar de diseño para interfaces de componentes 
no ha sido asentado y puede no ajustarse a ciertos 
componentes reutilizables existentes. 


Subcondición 3: Ciertos componentes reutilizables han sido implementados 
en un lenguaje no soportado por el entorno para el que 
el sistema ha sido construido. 


Reducción/Supervisión: 
Contactar con terceras personas para determinar 
la conformidad con los estándares de diseño. 
Presionar para completar los estándares de la interfaz; 
considerar la estructura de componentes cuando se decide 
el protocolo de la interfaz. 
Comprobación para determinar los componentes en la 
categoria de subcondición 3; comprobación para determinar 
si se puede adquirir el soporte del lenguaje 


Gestión/Plan de Contingencia/Acción: 

5e calcula que la ER es de £20,200. Esta cantidad se coloca dentro del coste 
le contingencia del proyecto. La planificación del proyecto revisado asume 
jue setendrán que construir 18 componentes adicionales; por consiguiente 
se asignará el personal de acuerdo con las necesidades. 

Acción: Las fases de reducción se llevarán a cabo a partir de 7/1/02 


FIGURA 6.5. Hoja de información de riesgo [WIL97]. 
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La seguridad del software y el análisis del peligro 
son actividades para garantizar la calidad del soft- 
ware (Capítulo 8) que se centra en la identificación 
y evaluación de peligros potenciales que pueden 
impactar al software negativamente y provocar que 
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falle el sistema entero. Si se pueden identificar los 
peligros al principio del proceso de ingeniería del 
software, se pueden especificar características de dise- 
ño software que eliminen o controlen esos peligros 
potenciales. 


Se puede incluir una estrategia de gestión de riesgo en el 
plan del proyecto de software O se podrían organizar los 
pasos de gestión del riesgo en un Plan diferente de reduc- 
ción, supervisión y gestión del riesgo (Plan RSGR). Todos 
los documentos del plan RSGR se llevan a cabo como 
parte del análisis de riesgo y son empleados por el jefe 
del proyecto como parte del Plan del Proyecto general. 


Plan RSGR 


Algunos equipos de software no desarrollan un docu- 
mento RSGR formal. Más bien, cada riesgo se docu- 
menta utilizando una hoja de información de riesgo 
(HIR) [WIL97]. En la mayoría de los casos, la HZR se 
mantiene utilizando un sistema de base de datos, por lo 


que la creación y entrada de información, ordenación 
por prioridad, búsquedas y otros análisis pueden ser rea- 
lizados con facilidad.. El formato de la HIR se muestra 
en la Figura 6.5. 

Una vez que se ha desarrollado el plan RSGR y el 
proyecto ha comenzado, empiezan los procedimientos 
de reducción y supervisión del riesgo. Como ya hemos 
dicho antes, la reducción del riesgo es una actividad para 
evitar problemas. La supervisión del riesgo es una acti- 
vidad de seguimiento del proyecto con tres objetivos 
principales: (1) evaluar cuando un riesgo previsto ocu- 
rre de hecho; (2) asegurarse de que los procedimientos 
para reducir el riesgo definidos para el riesgo en cues- 
tión se están aplicando apropiadamente; y (3) recoger 
información que pueda emplearse en el futuro para ana- 
lizar riesgos. En muchos casos, los problemas que ocu- 
rren durante un proyecto pueden afectar a más de un 
riesgo. Otro trabajo de la supervisión de riesgos es inten- 
tar determinar el origen -qué  riesgo(s) ocasionaron tal 
problema a lo largo de todo el proyecto—. 


Cuando se pone mucho en juego en un proyecto de soft- 
ware el sentido común nos aconseja realizar un análisis 
de riesgo. Y sin embargo, la mayoría de los jefes de pro- 
yecto lo hacen informal y superficialmente, si es que lo 
hacen. El tiempo invertido identificando, analizando y 
gestionando el riesgo merece la pena por muchas razo- 
nes: menos trastornos durante el proyecto, una mayor habi- 
lidad de seguir y controlar el proyecto y la confianza que 
da planificar los problemas antes de que ocurran. 


El análisis de riesgos puede absorber una cantidad 
significativa del esfuerzo de planificación del proyec- 
to. Pero el esfuerzo merece la pena. Por citar a Sun Tzu, 
un general chino que vivió hace 2.500 años, « Si cono- 
ces al enemigo y te conoces a ti mismo, no tendrás que 
temer el resultado de cien batallas». Para el jefe de pro- 
yectos de software, el enemigo es el riesgo. 
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neering Institute, CMU/SEI-93-TR-6, 1993. 


[THO92] Thomsett, R., «The Indiana Jones School of Risk 
Management», American Programmer, vol. 5, n.? 7, Sep- 
tiembre 1992, pp. 10-18. 


[WIL97] Williams, R.C., J.A.Walker y A.J. Dorofee, «Put- 
ting Risk Management into Practice», [EEE Software, 
Mayo 1997, pp. 75-81. 


6.1. Proporcione cinco ejemplos de otros campos que ilustren 
los problemas asociados con una estrategia reactiva frente al 
riesgo. 


6.2. Describa la diferencia entre «riesgos conocidos» y «ries- 
gos predecibles». 


6.3. Añada tres cuestiones o temas a cada una de las listas de 
comprobación de elementos de riesgo que se presentan en el 
sitio web SEPA. 


6.4. Se le ha pedido que construya un software que soporte un 
sistema de edición de vídeo de bajo coste. El sistema acepta 
cintas de vídeo como entrada de información, almacena el 
vídeo en disco, y después permite al usuario realizar un amplio 
abanico de opciones de edición al vídeo digitalizado. El resul- 
tado (salida) se envía a una cinta. Realice una pequeña inves- 
tigación sobre sistemas de este tipo, y después haga una lista 
de riesgos tecnológicos a los que se enfrentaría al comenzar 
un proyecto de este tipo. 


6.5. Usted es eljefe de proyectos de una gran compañía de 
software. Se le ha pedido que dirija a un equipo que está 
desarrollando un software de un procesador de textos de 
«nueva generación» (ver Sección 3.4.2 para obtener una bre- 
ve descripción). Construya una tabla de riesgo para el pro- 
yecto. 


6.6. Describa la diferenciaentre componentes de riesgo y con- 
troladores de riesgo. 


6.7. Desarrolle una estrategia de reducción del riesgo y sus 
actividades específicas para tres de los riesgos señaladosen la 
Figura 6.2. 


6.8. Desarrolle una estrategia de supervisión del riesgo y sus acti- 
vidades específicas para tres de los riesgos señalados en la Figu- 
ra 6.2. Asegúrese de identificar los factores que va a supervisar 
para determinar si el riesgo se hace más o menos probable. 


6.9. Desarrolle una estrategia de gestión del riesgo y sus acti- 
vidades específicas para tres de los riesgos señalados en la 
Figura 6.2. 


6.10. Trate de refinar tres de los riesgos señalados en la figura 
6.2 y realice las hojas de informacióndel riesgo para cada uno. 


6.11. Represente 3 de los riesgos señaladosen la figura 6.2 uti- 
lizando el formato CTC. 


6.12. Vuelva a calcular la exposición al riesgo tratada en la 
Sección 6.4.2 donde el coste/LDC es £16 y la probabilidad es 
del 60 por 100. 


6.13. ¿Se le ocurre alguna situación en la que un riesgo de alta 
probabilidad y gran impacto no formará parte de su plan 
RSGR? 


6.14. Respecto a la referencia de riesgo mostrada en la Figu- 
ra 6.4, ¿será siempre la curva un arco simétrico como el que 
aparece, O habrá situaciones en las que la curva esté más dis- 
torsionada? Sies así, sugiera un escenario en el que esto pue- 
da ocurrir. 


6.15. Realice una investigación sobre aspectos de seguridad 
del software y escriba una pequeña redacción sobre el tema. 
Desarrolle un buscador web para obtener información actual. 


6.16. Describa cinco áreas de aplicación de softwareen las que 
la seguridad del software y el análisis de riesgo sean vitales. 


Las lecturas sobre la gestión del riesgo del software se han 
expandido significativamente en los Últimos años. Hall 
[HAL98] presenta uno de los tratados más completos del tema. 
Karolak [KAR96] ha escrito una guía que introduce un mode- 
lo de análisis del riesgo fácil de usar con listas de compro- 
bación y cuestionariosque merece la pena. Grey ha realizado 
una instantánea de la evaluación del riesgo (Practical Risk 
Assessmentfor Project Management, Wiley, 1995).Su trata- 
do abreviado proporciona una buena introducción al tema. 
Otros libros que merecen la pena son: 
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Chapman, C.B., y S. Ward, Project Risk Management: 
Processes, Techniques and Insights, Wiley, 1997. 


Schuyler, J. R., Decision Analysis in Projects, Project 
Management Institute Publications, 1997. 


Wideman, R. M. (editor), Project € Program Risk Mana- 
gement: A Guide to Managing Project Risk and Opportuni- 
ties, Project Management Institute Publications, 1998. 


Capers Jones (Assesmentand Control d Software Risks, 
Prentice-Hall, 1994)presenta un detallado estudio sobre ries- 
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gos del software que incluye información reunida de cientos 
de proyectos de software. Jones define 60 factores de riesgo 
que pueden afectar al resultado de los proyectos de softwa- 
re. Boehm [BOE89] sugiere unos excelentes cuestionarios y 
formatos de listas de comprobación que pueden resultar de 
valor incalculable a la hora de identificar riesgos. Charrette 
[CHA 89] presenta un detallado tratado de los mecanismos de 
análisis de riesgo, recurriendo a la teoría de probabilidades y 
técnicas estadísticas para analizar riesgos. En un volumen 
adjunto, Charette (Application Strategies for Risk Analysis, 
McGrawHill, 1990) analiza el riesgo en el contexto tanto del 
sistema como de la ingeniería del software y define unas estra- 
tegias pragmáticas para la gestión del riesgo. Gilb [GIL88] 
presenta un conjunto de «principios» (que son a menudo diver- 
tidos y algunas veces profundos) que pueden servir como una 
Úlil directriz para la gestión del riesgo. 
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Una 


Los tratados de Marzo 1995 de American Programmer, 
Mayo 1997 de IEEE Software, y Junio 1998 Cutter IT Jour- 
nal están dedicados a la gestión del riesgo. 

El Instituto de Ingenieríadel Software ha publicado muchos 
informes y guías detallados sobre el análisis y gestión del ries- 
go. El Air Force Systems Command Pamphlet AFSCP 800-45 
[AFC88] describe técnicas de identificación y reducción de 
riesgos. Todos los números de ACM Software Engineering 
Notes publican una sección titulada «Riesgos para el público» 
(editor, P. G. Neumann). Si quiere las últimas y mejores his- 
torias de horror de software, éste es el lugar adonde ir. 

En Internet están disponibles una gran variedad de fuen- 
tes de información relacionadas con temas de análisis y ges- 
tión del riesgo. Se puede encontrar una lista actualizada con 
referencias a sitios (páginas) web que son relevantes para el 
riesgo en http: //www.pressman5.com. 
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PLANIFICACIÓN TEMPORAL 
Y SEGUIMIENTO DEL PROYECTO 


finales de los años 60, un joven y brillante ingeniero fue elegido para «escribir» un pro- 

grama de computadora para una aplicación de fabricación automática. El motivo para 

su selección fue sencillo. Era la única persona de su grupo técnico que había asistido 
a un seminario de programación de computadoras. Sabía todo sobre el lenguaje ensamblador y 
Fortran, pero nada sobre ingeniería del software y mucho menos sobre la planificación tempo- 
ral y seguimiento del proyecto. 

Su jefe le dio los manuales adecuados y una descripción verbal de lo que tenía que hacer. Se 
le informó de que el proyecto debía terminarse en dos meses. 

Leyó los manuales, consideró su enfoque y empezó a escribir código. Después de dos sema- 
nas de trabajo, el jefe le llamó a su oficina y le preguntó qué tal iban las cosas. 

«Muy bien», dijo el joven ingeniero con entusiasmo juvenil, «es más fácil de lo que pen- 
saba. He terminado cerca del 75 por 100». 

El jefe sonrió. «Es realmente estupendo», dijo, alentando al joven ingeniero a que siguiera 
trabajando del mismo modo. Acordaron que se reunirían otra vez en una semana. 

Una semana más tarde el jefe llamó al ingeniero a su oficina y le preguntó: «¿Por dónde 
vamos?» 

«Todo va muy bien», dijo el joven, «pero me he encontrado con unos pequeños obstáculos. 
Los solucionaré y volveré al ritmo de trabajo pronto.» 

«¿Cómo ves las fechas límite de entrega?», preguntó el jefe. 

«No hay problema», dijo el ingeniero, «estoy cerca de terminar el 90 por 100». 

Si ha estado trabajando en el mundo del software durante algunos años, sabrá el final de la hts- 
toria. No es una sorpresa que el joven ingeniero! se estancara en el 90 por 100 durante el resto del 
proyecto y que terminara (con la ayuda de otros) con un mes de retraso. 

Esta historia se ha repetido docenas de miles de veces con los desarrolladores de software 
durante las últimas tres décadas. La gran pregunta es ¿por qué? 


VISTAZO RÁPIDO 


lizan la información solicitada a los 


¿Qué es? Usted ha seleccionado un mode- 
lo de proceso adecuado, ha identificado 
las tareas de ingeniería del software 
que hay que llevar a cabo, ha estimado 
la cantidad de trabajo y el número de 
personas necesario, conoce las fechas 
límite de entrega e incluso ha conside- 
rado los riesgos. Ahora es el momento 
de unir todos los puntos. Esto es, tiene 
que crear una red de tareas de ingenie- 
ría del software que le permitan conse- 
guir el trabajo realizado dí tiempo. Una 
vez creada la red, tiene que asignar la 
responsabilidad para cada tarea, ase- 
gúrese de hacerlo y de adaptar la red 
antes de que los riesgos se conviertan 
en realidad. En resumidas cuentas, esto 
es la planificación temporal y el segui- 
miento del proyecto de software. 


¿Quién lo hace? A nivel de proyecto, los 
gestores de proyectos de software, uti- 


ingenieros de software. Á nivel indivi- 
dual, los mismos ingenieros de soft- 
ware. 


¿Por qué es importante? Para cons- 


truir un sistema complejo, muchas 
tareas de ingeniería del software se 
realizan en paralelo y el resultado del 
trabajo desarrollado durante una tarea 
puede tener un gran efecto en el tra- 
bajo a realizar en otra tarea. Estas 
interdependencias son muy difíciles 
de comprender sin una planificación. 
También es virtualmente imposible 
evaluar el progreso en un proyecto de 
software normal o grande sin una pla- 
nificación detallada. 


¿Cuáles son los pasos? Las tareas de 


ingeniería del software dictadas por el 
modelo de proceso del software son 
refinadas por la funcionalidad a cons- 


| Si se pregunta si esta historia es autobiográfica, ¡lo es! 
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truir. El esfuerzo y la duración se asig- 
na a cada tarea y se crea una red de 
tareas (tambien llamada red de activi- 
dades) que permita al equipo de soft- 
ware conseguir la fecha límite de 
entrega establecida. 


¿Cuál es el producto obtenido? Se 


obtiene la planificación del proyecto e 
información relacionada. 


¿Cómo puedo asegurar que lo he 


hecho correctamente? Una plani- 
ficación adecuada requiere que (1) 
todas las tareas aparezcan en la red; 
(2) el esfuerzo y el tiempo se asigne 
inteligentemente a cada tarea; (3) las 
relaciones entre tareas estén indica- 
das correctamente; (4) los recursos sean 
asignados al trabajo a realizar, y (5) los 
hitos se sitúen rigurosamente espa- 
ciados para que se pueda seguir el pro- 
greso. 
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Aunque hay muchas razones por las que el software se 
entrega tarde, la mayoría pertenecen a una o más de las 
siguientes causas: 

+ Una fecha límite de entrega poco realista, estable- 
cida por alguien que no pertenece al grupo de inge- 
niería del software e impuesta a los gestores y 
profesionales del grupo, 

+ Cambio de los requisitos del cliente que no se refle- 
jan en los cambios de la planificación temporal. 

» Una subestimación honesta de la cantidad de esfuerzo 
y/o el número de recursos que serán necesarios para 
hacer el trabajo. 

+ Riesgos predecibles y no predecibles que no se con- 
sideraron cuando comenzó el proyecto. 

+ Dificultades técnicas que no pudieron ser previstas 
por adelantado. 

+ Dificultades humanas que no pudieron ser previstas 
por adelantado. 

+ Falta de comunicación entre la plantilla del proyecto 
que causa retrasos. 

» Falta de reconocimiento por parte de la gestión del 
proyecto de su retraso y falta de medidas para corre- 
gir el problema. 


ines temporales irracionales 
on probablemente la influencia 
tivo en-el softwore. 


Las fechas límite de entrega agresivas (léase «poco 
realistas»), son un hecho consumado en el mundo del 
software. Algunas veces estas fechas límite se piden por 
motivos legítimos desde el punto de vista de la persona 
que las establece, pero el sentido común también dice que 
la legitimidad debe ser percibida por las personas que 
hacen el trabajo. 


7.1.1. Comentarios sobre los «retrasos» 


Napoleón dijo una vez: «Un comandante en jefe que 
acepta llevar a cabo un plan que considera defectuoso 
está cometiendo un error; debe exponer sus razones, 
insistir en cambiar el plan y finalmente presentar su 
dimisión antes de ser el instrumento de la destrucción 
de su ejército.» Duras palabras que muchos gestores de 
proyecto de software deberían considerar. 

Las actividades de estimación y análisis de riesgos 
estudiadas en los Capítulos 5 y 6, y las técnicas de pla- 
nificación temporal descritas en este capítulo, se imple- 
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mentan a menudo bajo la restricción de una fecha lími- 
te definida. Si las mejores estimaciones indican que la 
fecha límite es poco realista, un gestor de proyecto com- 
petente debería «proteger a su equipo de una presión 
[de la planificación temporal] innecesaria...[y] devol- 
ver la presión a quienes la originaron» [PAG85]. 


echas de entrega. Me gusta el sonido 
en cuando se aproximan. 
ms 


Para ilustrarlo, imagínese que un grupo de desarro- 
llo de software ha sido comisionado para construir un 
controlador de tiempo real para un instrumento médico 
de diagnóstico que quiere introducirse en el mercado en 
nueve meses. Después de una cuidadosa estimación y 
análisis de riesgos, el gestor del proyecto de software 
llega a la conclusión de que el software, tal y como se 
ha pedido, requerirá 14 meses para crearlo con la plan- 
tilla de la que se dispone. ¿Cómo debe proceder el jefe 
del proyecto? 

Es poco realista ir a la oficina del cliente (en este 
caso el cliente probable es mercadotecnia/ventas) y exi- 
girle que se cambie la fecha de entrega. Las presiones 
externas del mercado han dictado la fecha y el produc- 
to debe entregarse. También es absurdo rechazar el tra- 
bajo (desde el punto de vista de la carrera profesional). 
Así pues, ¿qué hacer? 


Qué deberíamos hacer 
cuando la gestión exige 
que cumplamos una fecha límite 
de entrega que es imposible? 


Se recomiendan los siguientes pasos en esta situación: 


l. Realice una estimación detallada usando informa- 
ción de proyectos anteriores. Determine el esfuerzo 
estimado y la duración del proyecto. 


Empleando un modelo de proceso incremental (Capf- 
tulo 2), establezca una estrategia de desarrollo que 
proporcione una funcionalidad crítica mínima para 
la fecha límite impuesta, pero deje otras funcionali- 
dades para más tarde. Documente el plan. 


. Reúnase con el cliente y (empleando la estimación 
detallada) explique por qué la fecha límite impuesta 
no es realista. Asegúrese de apuntar que todas las esti- 
maciones se basan en proyectos del pasado. Asegú- 
rese también de indicar la mejora de porcentaje que 
se requerirá para conseguir la fecha límite tal y como 
está ahora”. El siguiente comentario sería apropiado: 


2 Si la mejora de porcentaje es del 10 al 25 por ciento, puede ser posi- 
ble, de hecho, terminar el trabajo. Pero si se necesita que la mejora 
del porcentaje en el rendimiento del equipo sea mayor del 50 por 
ciento. Esta es una previsión no realista. 
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«Creo que podemos tener un problema con la fecha 
de entrega del software de controlador XYZ. Les he 
entregado a cada uno de ustedes una descomposición 
abreviada de los ritmos de producción de proyectos 
anteriores y una estimación que hemos hecho de varias 
maneras diferentes. Se fijarán en que he asumido un 
20 por 100 de mejora con respecto a los ritmos de pro- 
ducción del pasado, pero todavía obtenemos una fecha 
de entrega que está más bien a 14 meses de calenda- 
rio que a 9 meses de la presente fecha.» 


Los modelos de procesos incrementales se estudian 
en el Copítulo 2. 


. Oferte la estrategia de desarrollo incremental como 
alternativa. 


«Tenemos pocas opciones y me gustaría que toma- 
ran una decisión basándose en ellas. Primero, pode- 
mos aumentar el presupuesto y conseguir recursos 
adicionales de manera que tengamos la oportunidad 
de tener el trabajo hecho en nueve meses, pero entien- 
dan que esto aumenta el riesgo de poca calidad debi- 
do a lo apretado de las fechas?. 

Segundo, podemos quitar un número determina- 
do de funciones software y capacidades de las que 
piden. Esto hará la versión preliminar del producto 
algo menos funcional, pero podemos anunciar la fun- 
cionalidad completa para lanzarla a los 14 meses. 
Tercero, podemos contradecir a la realidad y desear 
poder completarlo en 9 meses. Nos encontraremos 
con algo que no se pueda entregar a un cliente de 
manera alguna. La tercera opción, espero que estén 
de acuerdo, es inaceptable. Nuestra experiencia y 
nuestras mejores estimaciones dicen que es poco rea- 
lista y una receta para el desastre.» 


Habrá gruñidos, pero si se presentan estimaciones 
sólidas basadas en una buena información histórica, es 
probable que se opte por alguna versión negociada de 
las opciones 1 6 2, La fecha límite no realista se desva- 
necerá. 


7.1.2. Principios básicos 


A Fred Brooks, el conocido autor de The Mythical 
Man-Month [BRO95], se le preguntó una vez cómo se 
retrasan las planificaciones temporales de los proyec- 
tos. Su respuesta fue tan simple como profunda: «Dia- 
riamente.» 

La realidad de un proyecto técnico (tanto si implica 
la construcción de una planta hidroeléctrica o desarro- 
llar un sistema operativo) es que hay que realizar cien- 
tos de pequeñas tareas antes de poder alcanzar el 
objetivo final. Algunas de estas tareas quedan fuera del 


3 Puede añadir que agregar más personal no reducirá la planificación 
temporal proporcionalmente. 
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camino principal y pueden completarse sin preocupar- 
se del impacto en la fecha de terminación del proyecto. 
Otras tareas se encuentran en el «camino crítico»”, Si 
estas tareas «críticas» se retrasan, la fecha de termina- 
ción del proyecto entero se pone en peligro. 


Cons) 


Los tareas requeridas para lograr el objetivo 

de los gestores del proyecto no se deberían realizar 
manualmente. Hay muchos herramientas excelentes 
de planificación de proyectos. Utificelas. 


El objetivo del gestor del proyecto es definir todas 
las tareas del proyecto, construir una red que describa 
sus interdependencias, identificar las tareas que son crí- 
ticas dentro de la red y después hacerles un seguimien- 
to para asegurarse de que el retraso se reconoce «de 
inmediato». Para conseguirlo, el gestor debe tener una 
planificación temporal que se haya definido con un gra- 
do de resolución que le permita supervisar el progreso 
y controlar el proyecto. 

La planificación temporal de un proyecto de soft- 
ware es una actividad que distribuye el esfuerzo esti- 
mado a lo largo de la duración prevista del proyecto, 
asignando el esfuerzo a las tareas específicas de la inge- 
niería del software. Es importante resaltar, sin embar- 
go, que la planificación temporal evoluciona con el 
tiempo. Durante las primeras etapas de la planificación 
del proyecto, se desarrolla una planificación temporal 
macroscópica. Este tipo de planificación temporal iden- 
tifica las principales actividades de la ingeniería del soft= 
ware y las funciones del producto a las que se aplican. 
A medida que el proyecto va progresando, cada entra- 
da en la planificación temporal macroscópica se refina 
en una planificación temporal detallada. Aquí, se iden- 
tifican y programan las tareas del software específicas 
(requeridas para realizar una actividad). 


ión temporal demasiado optimista no 
s reales más cortos, sino más largos. 
Connell 


La planificación temporal para proyectos de desa- 
rrollo de software puede verse desde dos perspectivas 
bastante diferentes. En la primera se ha establecido ya 
(irrevocablemente) una fecha final de entrega de un sis- 
tema basado en computadora. La organización del soft- 
ware está limitada a distribuir el esfuerzo dentro del 
marco de tiempo previsto. El segundo punto de vista de 
la planificación temporal asume que se han estudiado 
unos límites cronológicos aproximados pero que la fecha 
final será establecida por la organización de la ingenie- 


4 El camino crítico se estudiará con más detalle, más adelante en este 
capítulo. 
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ría del software. El esfuerzo se distribuye para conse- 
guir el mejor empleo de los recursos, y se define una 
fecha final después de un cuidadoso análisis del soft- 
ware. Desgraciadamente, la primera situación es más 
frecuente que la segunda, 

Como todas las áreas de la ingeniería del software, 
la planificación temporal de proyectos de software se 
guía por unos principios básicos: 

Compartimentación. El proyecto debe dividirse en 
un número de actividades y tareas manejables. Para le- 
var a cabo está compartimentación, se descomponen 
tanto el producto como el proceso (Capítulo 3). 

Interdependencia. Se deben determinar las inter- 
dependencias de cada actividad o tarea compartimen- 
tada. Algunas tareas deben ocurrir en una secuencia 
determinada; otras pueden darse en paralelo. Algunas 
actividades no pueden comenzar hasta que el resultado 
de otras no esté disponible. Otras actividades pueden 
ocurrir independientemente. 


CLAVE 


Cuando realice una planificación temporal, 
compartimentalice el trabajo, represente interdependencias 
de tareas, asigne el esfuerzo y tiempo o cada tarea, defina 
responsabilidades para el trabajo a desarrollar, 

y defina los resultados y los hitos. 


Asignación de tiempo. A cada tarea que se vaya a pro- 
gramar se le debe asignar cierto número de unidades de 
trabajo (por ejemplo, personas-día de esfuerzo). Además, 


En un proyecto de desarrollo de software pequeño una 
sola persona puede analizar los requisitos, realizar el 
diseño, generar código y realizar las pruebas. A medi- 
da que crece el tamaño del proyecto más personas se 
ven envueltas. (Raramente podemos permitirnos el lujo 
de enfocar el esfuerzo de diez personas-año con una per- 
sona trabajando durante diez años.) 

Hay un mito común (estudiado en el Capítulo 1) que 
todavía creen muchos gestores responsables de esfuer- 
zos de desarrollo del software: «Si se retrasa el progra- 
ma, siempre podremos añadir más programadores y 
recuperar el ritmo más adelante en el proyecto.» Des- 
graciadamente, añadir gente tarde a un proyecto tiene a 
menudo un efecto negativo, provocando aún más retra- 
so. El personal agregado debe aprenderse el sistema y la 
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a cada tarea se le debe asignar una fecha de inicio y otra 
de finalización que son función de las interdependencias 
y de si el trabajo se hará a tiempo total o tiempo parcial. 

Validación de esfuerzo. Todos los proyectos tienen 
un número definido de miembros de la plantilla. A medi- 
da que se hace la asignación de tiempo, el gestor del 
proyecto debe asegurarse de que no se ha asignado un 
número de personas mayor que el de la plantilla en ese 
momento. Por ejemplo, considere un proyecto que tie- 
ne una plantilla asignada de tres miembros (por ejem- 
plo, 3 personas-día están disponibles por día de esfuerzo 
asignado”). Un día cualquiera, se deben realizar siete 
tareas concurrentemente. Cada tarea requiere 0,50 per- 
sonas-día de esfuerzo. Se ha asignado más esfuerzo del 
que pueden realizar las personas disponibles. 

Responsabilidades definidas. Cada tarea que se pro- 
grame debe asignarse a un miembro del equipo especí- 
fico. 

Resultados definidos. Cada tarea programada debe- 
ría tener un resultado definido. Para los proyectos de 
software, el resultado es normalmente un producto (por 
ejemplo, el diseño de un módulo) o una parte de un pro- 
ducto. Los productos se combinan frecuentemente en 
entregas. 

Hitos definidos. Todas las tareas o grupos de tareas 
deberían asociarse con un hito del proyecto. Se consi- 
gue un hito cuando se ha revisado la calidad de uno o 
más productos (Capítulo 8) y se han aceptado. 

Cada uno de los principios anteriores se aplica a 
medida que evoluciona la planificación temporal del 
proyecto. 


AS Y EL E 


gente que les enseña es la misma que estaba trabajando. 
Mientras están enseñando no se trabaja, y el proyecto se 
retrasa todavía más. 


Cons: 


Si debe añadir recursos a un proyecto con retraso, 
asegúrese de que les ha asignado trabajo altamente 
compartimentalizado. 


Además del tiempo que se tarda en aprender el sis- 
tema, el involucrar más personas aumenta el número de 
vías de comunicación y la complejidad de la comuni- 
cación a lo largo del proyecto. Aunque la comunicación 
es absolutamente esencial para el éxito del desarrollo 


$ En realidad, se dispone de menos de tres personas-día debido a reu- 
niones no mencionadas, enfermedades, vacaciones y otras razones. 
Para nuestro propósito, sin embargo, asumimos un 100 por 100 de 
disponúbilidad. 
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del software, cada nueva vía de comunicación requie- 
re un esfuerzo adicional y, por tanto, un tiempo adi- 
cional. 


7.2.1. Un ejemplo 


Considere cuatro ingenieros del software, cada uno 
capaz de producir 5000 LDC/año cuando trabajan en 
proyectos individuales. Cuando se pone a estos cuatro 
ingenieros en un proyecto de equipo, son posibles seis 
vías de comunicación potenciales. Cada vía de comu- 
nicación requiere un tiempo que podría de otra manera 
emplearse en desarrollar software. Asumiremos que la 
productividad del equipo (medida en LDC) se verá redu- 
cida en 250 LDC/año por cada vía de comunicación, 
debido al gasto indirecto asociado con la comunicación. 
Por tanto, la productividad del equipo es 20.000 -—(250 
x 6) = 18.500 LDC/año— un 7,5 por ciento menos de 
lo que podríamos esperar”. 

El proyecto de un año en el que está trabajando el 
equipo anterior se retrasa y a dos meses de la fecha 
de entrega se agregan dos personas adicionales al equi- 
po. El número de vías de comunicación se dispara a 
14. La productividad de la nueva plantilla es la equi- 
valente a 840 x 2 = 1.680 LDC para los dos meses 
restantes antes de la entrega. La productividad del 
equipo es ahora 20.000 + 1.680 - (250 x 14) = 18.180 
LDC/año. 


PS 
sÚ 
CLAVE 

Lo relación entre el número de personas que trabajan 


en un proyecto de software y la productividad total 
no es lineal. 


Aunque el ejemplo anterior es una burda simplifica- 
ción exagerada de las circunstancias del mundo real, 
sirve para ilustrar otro punto clave: la relación entre el 
número de personas que trabajan en un proyecto de soft- 
ware y la productividad global no es lineal. 


7.2.2, Una relación empírica 


Recordando la «ecuación del software» [PUT92] que 
se introdujo en el Capítulo 5, podemos demostrar la 
relación altamente no lineal entre el tiempo cronoló- 
gico para completar un proyecto y el esfuerzo huma- 
no aplicado al proyecto. El número de líneas de código 
entregadas (sentencias fuente), L, está relacionado 
con el esfuerzo y el tiempo de desarrollo por la ecua- 
ción: 


$ Es posible presentar un argumento en contra: la comunicación, si 
es efectiva, puede aumentar la calidad del trabajo que se está reali- 
zando, reduciendo, por tanto, la cantidad de repasos y aumentando 
la productividad individual de los miembros del equipo. ¡Todavía no 
hay veredicto final! 
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donde £ es el esfuerzo de desarrollo en personas-mes; 
P es un parámetro de productividad que refleja una varle- 
dad de factores que llevan a un trabajo de ingeniería del 
software de alta calidad (los valores típicos de P se 
encuentran entre 2.000 y 12.000); y tes la duración del 
proyecto en meses. 


Cons: 


Cuando la fecha límite de entrega es cada vez más 
ajustada, se alcanza un punto en el que el trabajo 
no se puede completar según la planificación, 

sin tener en cuenta el número de personas 

que lo estén realizando. Afronte la realidad 

y defino una nueva fecha de entrega. 


Despejando la ecuación del software anterior, pode- 
mos llegar a la expresión del esfuerzo de desarrollo E: 


E=I3/(P>f) (7.1) 


donde £ es el esfuerzo invertido (en personas-año) duran- 
te el ciclo entero de la vida del desarrollo del software y 
del mantenimiento, y t es el tiempo de desarrollo en años. 
La ecuación de esfuerzo de desarrollo puede relacionar- 
se con el coste de desarrollo con la inclusión de un fac- 
tor de coste laboral del trabajo ($/personas-año). 

Esto lleva a unos interesantes resultados. Considere 
un proyecto complejo de software de tiempo real esti- 
mado en 33.000 LDC, un esfuerzo de 12 personas-año. 
Si se han asignado ocho personas al equipo del proyecto. 
el proyecto puede estar terminado en 1,3 años. Sin 
embargo, si extendemos la fecha de finalización a 1,75 
años, la naturaleza altamente no lineal del modelo des- 
crito en la Ecuación (7.1) lleva a: 


E=LD/(PP)-38 personas-año 


Esto implica que extendiendo la fecha de finaliza- 
ción seis meses, ¡podemos reducir el número de perso- 
nas desde ocho hasta cuatro! La validez de estos 
resultados está abierta a debate, pero la implicación es 
clara: se pueden obtener beneficios usando menos gen- 
te durante un período de tiempo algo mayor para reali- 
zar el mismo trabajo. 


7.2.3. Distribución del esfuerzo 


Cada una de las técnicas de estimación del proyecto de 
software tratadas en el Capítulo 5 lleva a estimaciones 
de las unidades de trabajo (por ejemplo, personas-mes) 
requeridas para completar un desarrollo de software. Una 
distribución recomendada de esfuerzo en las fases de 


www.elsolucionario.net 


INGENIERÍA DEL SOFTWARE. UN ENFOQUE PHACTICO 


definición y desarrollo se conoce normalmente como la 
regla 40-20-40”. El cuarenta por ciento de todo el esfuer- 
zO O más se asigna a las tareas de análisis y diseño. Un 
porcentaje similar se aplica a las pruebas. Se puede dedu- 
cir correctamente que no se insiste mucho en la creación 
de código (un 20 por 100 del esfuerzo). 


Cuánto esfuerzo debería 
emplearse en cada una de 
las principales tareas de 
ingeniería del software? 


Esta distribución de esfuerzo debería usarse como 
una directriz solamente. Las características de cada 
proyecto dictan la distribución del esfuerzo. El esfuer- 
zo gastado en la planificación de un proyecto rara- 
mente supera más del 2 ó el 3 por 100, a no ser que 
el plan comprometa a una organización a grandes gas- 
tos por el gran riesgo. El análisis de los requisitos pue- 


den comprender de un 10 a un 25 por 100 del esfuer- 
zo del proyecto. El esfuerzo invertido en análisis o 
creación de prototipos debería crecer proporcional- 
mente con el tamaño y la complejidad del proyecto. 
Entre un 20 y un 25 por 100 del esfuerzo se aplica 
normalmente al diseño del software. También debe 
considerarse el tiempo empleado en la revisión del 
diseño y la repetición subsiguiente. 


Debido al esfuerzo aplicado al diseño de software, el 
código debería realizarse con relativa poca dificultad. Se 
puede alcanzar un rango del 15 al 20 por 100 del esfuer- 
zo global. Las pruebas y las subsiguientes depuraciones 
de errores pueden dar cuenta de entre un 30 y un 40 por 
100 restante del esfuerzo de desarrollo del software. La 
importancia del software dicta a menudo la cantidad de 
pruebas que se requieren. Si el software se ve desde el 
punto de vista humano (es decir, el fallo del software 
puede generar pérdidas de vidas humanas), se pueden 
considerar incluso porcentajes más altos. 


En el Capítulo 2 se describieron diferentes modelos de 
proceso. Estos modelos ofrecen paradigmas diferentes 
para el desarrollo del software. Independientemente de 
que un equipo de software elija un paradigma secuen- 
cial lineal, uno iterativo, uno evolutivo, uno concurrente 
o alguna combinación, el modelo de proceso está lleno 
de conjuntos de tareas que permiten al equipo del soft- 
ware definir, desarrollar y finalmente mantener el soft- 
ware de computadora. 

No hay un único conjunto de tareas que sea apropia- 
do para todos los proyectos. El conjunto de tareas que 
sería apropiado para un sistema grande y complejo sería 
considerado exagerado para un producto de software 
pequeño, relativamente sencillo. Por tanto, un proceso de 
software eficaz debería definir una colección de conjun- 
tos de tareas, cada una diseñada para satisfacer las nece- 
sidades de diferentes tipos de proyectos. 


PS 

7 
Ko 

CLAVE 

Un «conjunto de tareos» es una colección de entregas, 

hitos y tareas de ingeniería del software. 


Un conjunto de tareas es una colección de tareas de 
la ingeniería del software, hitos y entregas que deben 
realizarse para completar un proyecto particular. El con- 
junto de tareas a elegir debe proporcionar suficiente dis- 


7 Hoy en día, se recomienda normalmente aplicar al análisis y a las 
tareas de diseño de grandes proyectos de desarrollo de software más 
del 40 por 100 de todo el esfuerzo del proyecto. De ahí que el nom- 
bre de «40-20-40» no se aplique en un sentido estricto. 
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ciplina para alcanzar una alta calidad para el software. 
Pero, al mismo tiempo, no se debe cargar al equipo del 
proyecto con trabajo innecesario. 

Eos conjuntos de tareas se diseñan para acomodar 
diferentes tipos de proyectos y diferentes grados de rigor. 
Aunque es difícil desarrollar una completa taxonomía 
sobre los tipos de proyectos de software, la mayoría de 
las organizaciones de software encuentran proyectos de 
los siguientes tipos: 

I. Proyectos de desarrollo del concepto que se ini- 
cian para explorar algún nuevo concepto de negocios o 
aplicación de alguna nueva tecnología. 


IL. Proyectos de desarrollo de una nueva aplicación 
que se aceptan como consecuencia del encargo de un 
cliente específico. 


IL Proyectos de mejoras de aplicaciones que ocu- 
rren cuando un software existente sufre grandes modi- 
ficaciones de su funcionamiento, rendimiento o 
interfaces que son observables por el usuario final. 


IV. Proyectos de mantenimiento de aplicaciones que 
corrigen, adaptan o amplían un software existente en 
métodos que pueden no ser obvios de forma inmediata 
para el usuario final. 


V. Proyectos de reingeniería que se lleva a cabo con 
la intención de reconstruir un sistema existente (here- 
dado) en su totalidad o en parte. 
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Incluso dentro de un tipo de proyecto simple, hay 
muchos factores que influyen en el conjunto de tareas 
a elegir, Cuando se toman en combinación, estos fac- 
tores proporcionan una indicación del grado de rigor 

- con el que debería aplicarse el proceso del software. 


7.3.1. Grado de rigor 


El conjunto de tareos crecerá en tamaño y complejidad 
al mismo fiempo que crece el grado de rigor. 


Incluso para un proyecto de un tipo en particular, el gra- 
do de rigor con el que se aplica el proceso del softwa- 
re puede variar significativamente. El grado de rigor es 
función de muchas características del proyecto. Por 
ejemplo, los pequeños proyectos no críticos del nego- 
cio pueden ser tratados con algo menos de rigor que 
grandes y complejas aplicaciones críticas desde el pun- 
to de vista del negocio. Debe advertirse, no obstante, 
que todos los proyectos deben ejecutarse de manera que 
terminen en puntuales entregas de alta calidad. Se pue- 
den definir cuatro grados de rigor: 


Casual. Se aplican todas las actividades estructura- 
les del proceso (Capítulo 2), pero sólo se requiere un 
conjunto de tareas mínimo. En general, las tareas pro- 
tectoras se minimizarán y se reducirán los requisitos de 
documentación. Son aplicables todavía todos los prin- 
cipios básicos de la ingeniería del software. 


Estructurado. Se aplicará la estructura del proceso 
a este proyecto. Se aplicarán las actividades estructura- 
les y las tareas relativas apropiadas para el tipo de pro- 
yecto, así como las actividades protectoras necesarias 
para garantizar una alta calidad. Se llevarán a cabo SQA 
(GCS), documentación y tareas de medición de mane- 
ra fluida. 


Estricto. Se aplicará el proceso completo para este 
proyecto con un grado de disciplina tal que garantice una 
alta calidad. Se aplicarán todas las actividades protecto- 
ras y se producirá una robusta documentación. 


Reacción rápida. Se aplicará la estructura del pro- 
ceso a este proyecto, pero debido a una situación de 
emergencia”, sólo se aplicarán aquellas tareas esen- 
ciales para mantener una alta calidad. Se realizará un 
«back-filling» (es decir, desarrollar un conjunto com- 
pleto de documentación, realizar revisiones adicio- 
nales) después de entregar la aplicación/producto al 
cliente. 


$ Las situaciones de emergencia deberían ser raras (no debería ocu- 
rrir en más de un 10 por 100 de todo el trabajo realizado dentro del 
contexto de la ingeniería del software). Una emergencia no es lo 
mismo que un proyecto con apretadas limitaciones de tiempo. 
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Si todo es una emergencia, habrá algo mal en su proceso 
del software o en las personas que lo dirigen o en ambos. 


El gestor del proyecto debe desarrollar un enfoque 
sistemático para seleccionar el grado de rigor apropia- 
do para cada proyecto. Para conseguirlo, se definen unos 
criterios de adaptación del proyecto y se calcula un valor 
selector del conjunto de tareas. 


7.3.2. Definir los criterios de adaptación 


Los criterios de adaptación se emplean para determi- 
nar el grado de rigor recomendado con el que el proce- 
so del software debería aplicarse en un proyecto. Se 
definen once criterios de adaptación para proyectos de 
software [PRE99]: 


+ "Tamaño del proyecto. 

+» Número potencial de usuarios. 

+ Importancia de la misión. 

»  Antigúedad de la aplicación. 

+ Estabilidad de los requisitos. 

* Facilidad de comunicación cliente/desarrollador. 
- Madurez de la tecnología aplicable. 

+ Limitaciones de rendimiento. 

» Características empotradas/no empotradas. 
» Personal del proyecto. 

* Factores de reingeniería. 


Modelo de proceso adaptable 


A cada uno de los criterios de adaptación se le asig- 
na un grado que va desde 1 hasta 5, donde 1 represen- 
ta un proyecto en el que se requiere un pequeño 
subconjunto de tareas de proceso, y los requisitos gene- 
rales metodológicos y de documentación son mínimos, 
y 5 representa un proyecto en el que se debería aplicar 
un conjunto completo de tareas de proceso y en el que 
los requisitos generales metodológicos y de documen- 
tación son sustanciales. 


7.3.3. Cálculo del valor selector del conjunto 

de tareas 
Para seleccionar el conjunto apropiado de tareas para 
un proyecto, se deberían seguir los siguientes pasos: 
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Il. Revise cada uno de los criterios de adaptación en la 
Sección 7.3.2 y asigne los grados apropiados (1 a 5) 
basándose en las características del proyecto. Estos 
grados deberían introducirse en la Tabla 7.1. 


¿Cómo elegimos el conjunto 
de tareas apropiado para 
nuestro proyecto? 


Criterios de Adaptación Grado Peso Multiplicador de punto de entrada Producto 


Concur. Ndev. Mejora  Mant. Reing. 


Tamaño del proyecto a 1,20 0 1 1 1 1 E 
Número de usuarios OS 1,10 0 1 1 1 1 A 
Importancia para el negocio ÓN 1,10 0 1 1 1 1 a 
Antigúedad o 0,90 0 1 1 0 0 E 
Estabilidad de los requisitos a 1,20 0 1 1 1 1 O 
Facilidad de Comunicación oo 0,90 1 1 1 1 1 o 
Madurez de la tecnología a 0,90 1 1 0 0) 1 A 
Limitaciones de rendimiento O 0,80 0) 1 1 0 1 ES 
Empotrado/no empotrado pa 1,20 1 1 1 0 1 A 
Personal del proyecto ON 1,00 1 1 1 1 1 a 
Interoperabilidad o 1,10 0 1 1 1 1 E 
Factores de reingeniería A 1,20 0 0 0 0 1 A 
Selector de conjunto de tareas (SCT) 7 
TABLA 7.1. CÁLCULO DEL SELECTOR DEL CONJUNTO DE TAREAS. UN EJEMPLO 
2. Revise los factores de ponderación asignados a O y 1, e indica la importancia del criterio de adaptación 

cada criterio. El valor de un factor de ponderación para el tipo de proyecto. El resultado del producto: 

pe oo E os le A e e nas Grado x factor de ponderación x multiplicador 

la relativa importancia de un criterio de adaptación d 

Me a . e punto de entrada 

en particular a los tipos de software desarrollados 

dentro del entorno local. Si son necesarias modifi- se coloca en la columna Producto de la Tabla 7.1 

caciones para reflejar mejor las circunstancias loca- para cada criterio de adaptación individual. 

les, se deberían hacer. 4. Calcule la media de todas las entradas en la columna 
3. Multiplique el grado introducido en la Tabla 7.1 por el Producto y ponga el resultado en el espacio mar- 

factor de ponderación (peso) y por el multiplicador cado selector del conjunto de tareas (SCT). Este valor 

de punto de entrada del tipo de proyecto a realizar. El se usará para ayudarle a seleccionar el conjunto de 

multiplicador de punto de entrada toma un valor entre tareas más apropiado para el proyecto. 
Criterios de Adaptación Grado Peso Multiplicador de punto de entrada Producto 


Concur. Ndev. —MWlejora  MVant. Reing. 


Tamaño del proyecto 2 1,2 a 1 2,4 
Número de usuarios 3 1,1 AS 1 3,3 
Importancia para el negocio 4 1,1 o 1 4,4 
Antiguedad 3 0,9 o 1 21 
Estabilidad de los requisitos 2 1,2 a 1 2,4 
Facilidad de Comunicación 2 0,9 A 1 1,8 
Madurez de la tecnología 2 0,9 a 1 1,8 
Limitaciones de rendimiento 3 0,8 OS 1 2,4 
Empotrado/no empotrado 3 1,2 A 1 3,6 
Personal del proyecto 2 1,0 E 1 2,0 
Interoperabilidad 4 1,1 A 1 4,4 
Factores de reingeniería 0 1,2 EH 0 0,0 
Selector de conjunto de tareas (SCT) 2,8 


TABLA 7.2. CÁLCULO DEL SELECTOR DEL CONJUNTO DE TAREAS. UN EJEMPLO 
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7.3.4. Interpretar el valor SCT y seleccionar 
el conjunto de tareas 


Una vez que se ha calculado el selector del conjunto de 
tareas, se pueden utilizar las siguientes directrices para 
seleccionar el conjunto de tareas apropiado para un pro- 
yecto: 


Valor del selector 


del conjunto de tareas Grado de rigor 


SCT < 1,2 Casual 
10<SCT<3,0 Estructurado 
SCT > 2,4 Estricto 


Cons 


Si el valor del selector del conjunto de tareas es un área 
solapada, normalmente es correcto elegir el menor grado de 
rigor fosmal, a no ser que el riesgo del proyecto sea alto. 


El solapamiento en los valores SCT de un conjunto 
de tareas recomendado con otro está hecho a propósi- 
to y pretende ilustrar que no son posibles unas fronte- 
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ras tan definidas cuando se seleccionan conjuntos de 
tareas. En el análisis final, el valor del selector del con- 
junto de tareas, la experiencia acumulada y el sentido 
común deben tenerse en cuenta en la elección del con- 
junto de tareas para el proyecto. 


La Tabla 7.2 ilustra cómo podría calcularse el SCT 
para un hipotético proyecto. El gestor del proyecto selec- 
ciona los grados mostrados en la columna Grado. El 
tipo de proyecto es el desarrollo de una nueva aplica- 
ción. Por tanto, los multiplicadores de punto de entra- 
da se seleccionan de la columna NDeyv. La entrada en 
la columna Producto se calcula empleando 


Grado x Peso x Multiplicador de punto 
de entrada Ndev(NewDevelop.) 


El valor de SCT (calculado corno la media de todas 
las entradas de la columna Producto) es 2,8. Usando los 
criterios estudiados anteriormente, el gestor tiene la 
opción de usar tanto el conjunto de tareas estructurado 
como el estricto. La decisión se toma una vez que se 
han considerado todos los factores del proyecto. 


Para desarrollar una planificación temporal del proyecto, 
se debe distribuir un conjunto de tareas a lo largo de la 
duración del proyecto. Como apuntamos en la Sección 
7.3 el conjunto de tareas variará dependiendo del tipo de 
proyecto y del grado de rigor. Cada uno de los tipos de 
proyectos descritos en la Sección 7.3 puede enfocarse 
usando un modelo de proceso lineal secuencial e iterati- 
vo (por ejemplo, el modelo incremental o de creación de 
prototipos) o evolutivo (por ejemplo, el modelo en espi- 
ral). En algunos casos, un tipo de proyecto fluye suave- 
mente hacia el siguiente. Por ejemplo, los proyectos de 
desarrollo de concepto que tienen éxito evolucionan a 
menudo en nuevos proyectos de desarrollo de aplicación. 
Cuando termina un proyecto de desarrollo de una nueva 
aplicación, empieza a veces un proyecto de mejora de la 
aplicación. Esta progresión es natural y predecible y ocu- 
rrirá sea cual sea el modelo de proceso que adopte una 
organización. Por consiguiente, las principales tareas de 
ingeniería del software descritas en las secciones siguien- 
tes son aplicables a todos los flujos del modelo de proce- 
so. Como ejemplo, consideremos las tareas principales de 
ingeniería para los proyectos de desarrollo de concepto. 


Un modelo de proceso adaptable 
(MPA) completo incluye una 
variedad de conjuntos de tareas 
y está disponible para su uso. 
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Los proyectos de desarrollo de concepto se inician 
cuando se debe explorar el potencial de alguna nueva 
tecnología. No hay certeza de que la tecnología sea apli- 
cable, pero el cliente (por ejemplo, marketing) cree que 
existe un beneficio potencial. Los proyectos de desa- 
rrollo de concepto se enfocan aplicando las siguientes 
tareas principales: 


Ámbito del concepto— determina el ámbito gene- 
ral del proyecto. 

Planificación preliminar del concepto— estable- 
ce la capacidad de la organización para llevar a cabo el 
trabajo implicado por el ámbito del proyecto. 

Valoración del riesgo tecnológico— evalúa el ries- 
go asociado con la tecnología a implementar como par- 
te del proyecto. 


Prueba de concepto — demuestra la viabilidad de 
una nueva tecnología en el contexto del software. 

Implementación del concepto— implementa la 
representación del concepto de manera que pueda revi- 
sarlo un cliente y se emplea para propósitos de «mar- 
keting» cuando hay que vender un concepto a otros 
clientes o departamentos de gestión. 

Reacción del cliente ante el concepto— solicita la opi- 
nión del cliente sobre un nuevo concepto de tecnología y 
va encaminada a aplicaciones específicas del cliente. 


No deberían producirse sorpresas si echamos un vis- 
tazo rápido a estas tareas principales. De hecho el flujo 
de las tareas de ingeniería del software para proyectos 
de desarrollo de concepto (y también para los otros tipos 
de proyectos) es poco más que sentido común. 
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El equipo del software debe entender lo que hay 
que hacer (ámbito); el equipo (o el gestor) debe deter- 
minar si hay alguien disponible para hacerlo (planifi- 
cación); debe considerar los riesgos asociados con el 
trabajo (valoración del riesgo); probar la tecnología 
de alguna manera (prueba de concepto); e implemen- 
tarlo en forma de prototipo de manera que el cliente 
pueda evaluarlo (implementación del concepto y eva- 
luación del cliente). Finalmente, si el concepto es via- 
ble, se debe fabricar una versión de producción 
(traducción). 

Es importante destacar que las actividades estructu- 
rales de las tareas de desarrollo de concepto son itera- 
tivas por naturaleza. Es decir, un proyecto de desarrollo 
de concepto cualquiera podría enfocar las tareas ante- 
riores en varios incrementos planificados, cada uno dise- 
ñado para producir una entrega que pueda ser evaluada 
por el cliente. 

Si se elige un modelo de proceso lineal, cada uno de 
estos Incrementos se define en una secuencia repetitiva 
como se ilustra en la Figura 7.1. Durante cada secuen- 
cia, se aplican actividades protectoras (descritas en el 
Capítulo 2); se supervisa la calidad, y al final de cada 
secuencia, se produce una entrega. Con cada iteración, 
cada entrega debería converger hacia el producto final 
definido para la fase de desarrollo de concepto. Si se 


elige un modelo evolutivo, la distribución de tareas de 
la L1 a la L6 aparecería como se muestra en la Figura 
7.2. Se pueden definir y aplicar de la misma manera las 
tareas principales de ingeniería del software para otros 
tipos de proyectos. 


Evaluación 
del cliente 


Definición 
del proyecto 


Ingeniería! 
Construcción 


Planificación Entrega 


-— Desarrollo del 


] 


1.1. Ámbito del 


concepto 


11 
concepto 


1.6. Reacción del cliente 


] 


implementación del concepto 


. Prueba del concepto | 


1.2. Planificación preliminar del conceptq |1.5. 


1.3. Valoración del riesgo tecnológico 


Proyectos de desarrollo 
de nueva aplicación 


Proyecto de mejora 
de la aplicación 


Mantenimiento 
de la aplicación 


——Reingeniería 


FIGURA 7.1. Tareas de desarrollo del concepto 
en un modelo secuencial lineal. 


Planificación 


Ingeniería/ 
Construcción 


Definición 


del proyecto 


A aplicación 

: >. Mantenimi 
Reingeniería | * te Amena 
de la aplicación 


Evaluación 
del cliente 


FIGURA 7.2. Tareas de desarrollo del concepto usando 
un modelo evolutivo. 


Entrega 


Las tareas principales descritas en la Sección 7.4 pue- 
den emplearse para definir una planificación tempo- 
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ral macroscópica para el proyecto. Sin embargo, la pla- 
nificación temporal macroscópica debe refinarse para 
crear una planificación temporal detallada del pro- 
yecto. El refinamiento se empieza tomando cada tarea 
principal y descomponiéndola en un conjunto de sub- 
tareas (con productos de trabajo e hitos relacionados). 

Como ejemplo de descomposición de tarea, consi- 
dere el Ambito del Concepto como un concepto del 
proyecto de desarrollo, estudiado en la Sección 7.4.1. 
Se puede refinar la tarea empleando un formato de bos- 
quejo, pero en este libro se emplea un enfoque de len- 
guaje de diseño de proceso para ilustrar el flujo de la 
actividad de ámbito del concepto: 


Definición de tarea: Tarea 1.1 Ámbito del concepto 
1.1.1. Identificar la necesidad, los beneficios y 
clientes potenciales; 

Definir el resultado/control deseado y las 
entradas que controlan la aplicación; 
Empezar la tarea 1.1.2 


LoLZs 


1.1.2.1, RTF: Revisar la descripción escrita de 
la necesidad ?; 
1.1.2.2. Obtener una lista de las entradas/sali- 


das visibles del cliente; 


? RTF indica que se debe realizar una revisión técnica formal (Capí- 
tulo 8). 
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Caso de: procedimientos 


Procedimientos = despliegue de la función 
calidad 


reunirse con el cliente para aislar los 
principales requisitos del concepto; 


entrevistar a los usuarios finales; 


observar el enfoque actual al problema, pro- 
ceso actual; 


revisar requisitos y quejas anteriores; 
Procedimientos = análisis estructurado 
hacer una lista de los objetos de datos 
principales; 
definir las relaciones entre los objetos; 
definir los atributos de los objetos; 
Procedimientos = visión del objeto 
hacer una lista de las clases de problemas; 
desarrollar la jerarquía de clases y las 
conexiones de clases; 
definir Tos atributos de las clasos; 
fin caso 
1.1.2.3. RTF: revisar las entradas/salidas con el 
cliente y adaptar según se requiera; 
Fin de tarea Tarea 1.1.2 
1.1.3. Definir la funcionalidad/comportamiento para 
cada función principal que es desarrollada; 
Empezar Tarea 1.1.3 


1.1.3.1. RTF: revisar los objetos de datos de 
entrada y salida obtenidos en la tarea 
1.1.3.2. Obtener un modelo de funciones/compor- 
tamientos; 
Caso de: procedimientos 
Procedimientos = Despliegue de la función 
calidad 


reunirse con el cliente para revisar los 
requisitos del concepto principal; 
entrevistar a los usuarios finales; 


observar el enfoque actual del problema, 
proceso actual; 


desarrollar un esquema jerárquico de fun- 
ciones /comportamientos; 


DEFINIR UNA BED DE TAREAS 


Las tareas y subtareas individuales tienen interdepen- 
dencias basadas en su secuencia. Además, cuando hay 
más de una persona implicada en un proyecto de inge- 
mería del software, es probable que las actividades de 
desarrollo y tareas se realicen en paralelo. Cuando ocu- 
rre esto, las tareas concurrentes deben coordinarse de 
manera que estén finalizadas cuando tareas posteriores 
requieran su(s) resultado(s). 


La red de tareas es un mecanismo útil 
pora representar la dependencia entre tareas 
y para determinar el carino crífico. 
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Procedimientos = Análisis estructurado 


obtener un diagrama de flujo de datos a nivel 
de contexto; 


refinar el diagrama de flujo de datos para 
proporcionar más detalles; 


escribir narrativas de proceso para las fun- 
ciones a más bajo nivel de refinamiento; 


Procedimientos = visión de objeto 


definir operaciones/métodos relevantes para 
cada clase; 


fin caso 
1.1.3.3. Revisar funciones/comportamientos con 
el cliente y revisar según sea necesa- 
rio; 
Fin de tarea Tarea 1.1.3 
1.1.4. Aislar aquellos elementos de la tecnología a 
implementar en software; 
1.1.5. Investigar la disponibilidad de información 
sobre el software existente; 


1.1.6. Definir viabilidad técnica; 
1.1.7. Hacer una estimación rápida del tamaño; 
1.1.8. Crear una definición de ámbito; 


Fin de tarea: Tarea 1.1 


El modelo de proceso adaptable 
(MPA) contiene una descripción 
del lenguaje de diseño de 
procesos completa para todas las 
tareas de ingeniería del software. 


Las tareas y subtareas apuntadas en el refinamiento 
del lenguaje de diseño del proceso forman la base para 
una planificación temporal detallada de las actividades 
del ámbito del concepto. 


Una red de tareas, también llamada red de activida- 
des, es una representación gráfica del flujo de tareas de 
un proyecto. Se emplea a veces como el mecanismo 
a través del cual. se introduce la secuencia de tareas y 
las dependencias en una herramienta de programación 
automática de la planificación temporal de un pro- 
yecto. En su forma más sencilla (la que se emplea en 
una planificación temporal macroscópica), la red de 
tareas muestra las tareas principales de ingeniería del 
software. La Figura 7.3 muestra una red de tareas 
esquemática para un proyecto de desarrollo de con- 
cepto. 

La naturaleza concurrente de las actividades de inge- 
niería del software lleva a varios requisitos importan- 
tes de la planificación temporal. Como las tareas 
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paralelas ocurren asíncronamente, el planificador debe 
determinar las dependencias entre las tareas para garan- 
tizar un progreso continuo hasta su finalización. Ade- 
más, el gestor del proyecto debería estar al tanto de las 
tareas que pertenecen al camino crítico. Es decir, tare- 
as que deben finalizarse según la planificación tempo- 
ral si se quiere que el proyecto en general se termine a 
tiempo. Estos aspectos se tratan con más detalle más 
adelante en este capítulo. 

Es importante resaltar que la red de tareas mos- 
trada en la Figura 7.3 es macroscópica. En una red 
de tareas detallada (el precursor de la planificación 
temporal detallada) cada actividad mostrada en la 
Figura 7.3 se expandiría. Por ejemplo, la Tarea 1.1 se 
expandiría para mostrar todas las tareas detalladas en 
el refinamiento de tareas 1.1 mostrado en la Sec- 
ción 7.5. 


Se aplican 3 tareas 1.5. 
en paralelo a 3 funciones 
de concepto diferentes 


Se aplican 3 tareas 1.3. 
en paralelo a 3 funciones 
de concepto diferentes 


FIGURA 7.3. Una red de tareas para un proyecto 
de desarrollo de concepto. 


La planificación temporal de un proyecto de software 
no difiere mucho del de cualquier esfuerzo de ingenie- 
ría multitarea. Por tanto, se pueden aplicar herramien- 
tas de planificación temporal de proyectos y técnicas 
generales al software con una pequeña modificación en 
los proyectos del software. 


Cons) 


Para los proyectos más sencillos, la planificación temporal 
debería realizarse con lo ayuda de una herramienta 
de planificación temporal de proyectos. 


La técnica de evaluación y revisión de programa 
(PERT) y el método del camino crítico (CPM) [MOD83] 
son dos métodos de la planificación temporal de un pro- 
yecto que pueden aplicarse al desarrollo de software. 
Ambas técnicas son dirigidas por la información ya desa- 
rrollada en actividades anteriores de la planificación del 
proyecto: 


+ Estimaciones de esfuerzo. 
+ Una descomposición de la función del producto. 


» La selección del modelo de proceso adecuado y del 
conjunto de tareas. 


» La descomposición de tareas. 


Las interdependencias entre las tareas deben defi- 
nirse empleando una red de tareas. Las tareas, a veces 
denominadas estructura de descomposición del tra- 
bajo del proyecto (en inglés, WBS), se definen para el 
producto como un todo o para las funciones indivi- 
duales. 

Tanto PERT como CPM proporcionan herramien- 
tas cuantitativas que permiten al planificador del soft- 
ware : (1) determinar el camino crítico, la cadena de 
tareas que determina la duración del proyecto; (2) esta- 
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blecer las dimensiones de tiempo «más probables» 
para las tareas individuales aplicando modelos esta- 
dísticos, y (3) calcular las limitaciones de tiempo que 
definen una «ventana» de tiempo de una tarea deter- 
minada. 

Los cálculos de las limitaciones de tiempo pueden 
ser muy útiles en la planificación temporal de proyec- 
tos de software. El retraso en el diseño de una función, 
por ejemplo, puede retardar el posterior diseño de otras 
funciones. Riggs [RIG81] describe importantes limita- 
ciones de tiempo que pueden discernirse de una red 
PERT o CPM: (1) lo antes posible que puede empezar 
una tarea cuando las tareas precedentes se completen 
también lo antes posible; (2) lo más tarde que se puede 
empezar una tarea antes de que se retrase el tiempo míni- 
mo para finalizar el proyecto; (3) la fecha más tempra- 
na de finalización —la suma de la fecha más temprana 
de inicio y la duración de la tarea—, (4) la fecha lími- 
te de finalización —la fecha más tardía de inicio suma- 
da a la duración de la tarea—, y (5) el margen total —la 
cantidad de tiempo extra o atrasos permitidos en la pla- 
nificación temporal de las tareas de manera que el cami- 
no crítico de la red se mantenga conforme a la 
planificación temporal—. Los cálculos de los tiempos 
límite llevan a la determinación del camino crítico y 
proporcionan al gestor un método cuantitativo para eva- 
luar el progreso a medida que se completan las tareas. 


Herramientas CASE 
para la planificación temporal 
y programación del proyecto. 
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Tanto PERT como CPM se han implementado en 
varias herramientas automáticas disponibles virtual- 
mente para todos los ordenadores personales [THE93]. 
Tales herramientas son fáciles de usar y hacen asequi- 
bles los métodos de la planificación temporal descritos 
anteriormente a todos los gestores de proyectos de soft- 
ware. 


7.7.1. Gráficos de tiempo 


Cuando se crea una planificación temporal de un pro- 
yecto de software, el planificador empieza un con- 
junto de tareas (la estructura de descomposición del 
trabajo). Si se emplean herramientas automáticas, la 
descomposición del trabajo es introducida como una 
red de tareas o esquema de tareas. El esfuerzo, dura- 
ción y fecha de inicio son las entradas de cada tarea. 


Tareas Semana 1 


11.1 Identificar necesidades y beneficios 


Reunirse con los clientes 


Identificar las necesidades y las limitaciones 
del proyecto 
Establecer la declaración de producto 
Hito: declaración de producto definida 
11.2 Definir fas salidas/controlV/entradas deseadas (SCE) 
Alcance de las funciones del teclado 


Alcance de las funciones de entrada de voz 


Alcance de los modos de interacción 
Alcance de documento de diagnósticos 
Alcance otras funciones WP 
Documento SCE 
RTF: revisar el SCE con el cliente 
Revisar el SCE según se requiera 
Hito: SCE definido 
1.1.3 Definir la funcionalidad/comportamiento 

efinir las funciones del teclado 
Definir las funciones de entrada de voz 
Describir los modos de interacción 
Describir las comprobaciones de ortografía! 
gramática 
Describir otras funciones WP 

TF: Revisar la definición SCÉE con el cliente 
Revisar según sea necesario 
Hito: Definición de SCE completa 
11.4 Aislar los elementos software 
Hito: Elementos software definidos 
11.55 Investigar la disponibilidad del software existente 
nvestigar los componentes de edición de texto 
nvestigar los componentes de la entrada de voz 
Investigar los componentes de la administración 
de archivos 
nvestigar los componentes de la comprobación 
de ortografía y gramática 
Hito: Componentes reutilizables identificados 
11.6 Definir la viabilidad técnica 
Evaluar la entrada de voz 
Evaluar la comprobación de gramática 
Hito: Viabilidad técnica valorada 
11.7 Hacer una estimación rápida del tamaño 
1.1.8 Crear una definición de ámbito 
Revisar el documento de ámbito con el cliente 


Revisar el documento según se requiera 


Hito: Documento de ámbito completo 


FIGURA 7.4. Un ejemplo de gráfico de tiempo. 


Semana 2 
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Además, se asignan las tareas a individuos específicos. 


e 
CLAVE 


Un gráfico de tiempo le permite conocer qué tareos serán 
conducidas en un punto determinado en el tiempo. 


S 


Como consecuencia de esta entrada, se genera un 
gráfico de tiempo, también denominado Gráfico Gantt. 
Se puede desarrollar un gráfico de tiempo para todo el 
proyecto. Alternativamente, se pueden desarrollar dife- 
rentes gráficos para cada función del proyecto o para 
cada individuo que trabaje en el proyecto. 


Semana 3 Semana 4 Semana 5 
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La Figura 7.4 ilustra el formato de un gráfico de tiem- 
po. Muestra una parte de la planificación temporal de 
un proyecto de software que enfatiza la tarea de ámbi- 
to del concepto (Sección 7.5) para un nuevo producto 
de software de procesador de textos. Todas las tareas 
del proyecto (para ámbito del concepto) se listan en la 
columna de la izquierda. Las barras horizontales indi- 
can la duración de cada tarea. Cuando aparecen múlti- 
ples barras al mismo tiempo en la planificación temporal, 
implican concurrencia de tareas. Los rombos indican 
hitos. 

Una vez que se ha introducido la información nece- 
saria para generar el gráfico de tiempo, la mayoría de 
las herramientas de la planificación temporal de pro- 
yectos de software producen tablas de proyecto —un 
listado tabular de todas las tareas del proyecto, sus 
fechas previstas y reales de inicio y finalización, e 
información varia relativa al tema— (Fig. 7.5). Em- 
pleando las tablas junto con los gráficos de tiempo, le 
permiten al gestor del proyecto hacer un seguimiento 
del progreso. 


7.7.2. Seguimiento de la planificación temporal 


La planificación temporal del proyecto le proporcio- 
na al gestor un mapa de carreteras. Si se ha desarro- 
llado apropiadamente, define las tareas e hitos que 
deben seguirse y controlarse a medida que progresa el 
proyecto. El seguimiento se puede hacer de diferentes 
maneras: 

«realizando reuniones periódicas del estado del pro- 
yecto en las que todos los miembros del equipo infor- 
man del progreso y de los problemas; 

» evaluando los resultados de todas las revisiones reali- 
zadas a lo largo del proceso de ingeniería del software; 


elos informes de estado del 
e resumirse en una frase: «¡ninguna 


+ determinando si se han conseguido los hitos forma- 
les del proyecto (los rombos mostrados en la Fig. 7.4) 
en la fecha programada; 

* comparando la fecha real de inicio con las previstas 
para cada tarea del proyecto listada en la tabla del 
proyecto (Fig. 7.5); 

+  reuniéndose informalmente con los profesionales del 
software para obtener sus valoraciones subjetivas del 


10 Es importante resaltar que un retraso del programa es un síntoma 
de algún problema oculto. El papel del gestor es diagnosticar cuál es 
el problema y actuar para corregirlo. 
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progreso hasta la fecha y los problemas que se ave- 
cinan, O 

+ utilizando el análisis del valor ganado (Sección 7.8) 
para evaluar el progreso cuantitativamente. 


Cons) 


El mejor indicador del progreso es la finalización 
y la revisión exitosa de un producto de software. 


El control lo usa el gestor para administrar los recur- 
sos del proyecto, enfrentarse a los problemas y dirigir 
al personal del proyecto. Si las cosas van bien (es decir, 
el proyecto va según la planificación temporal y dentro 
del presupuesto, las revisiones indican que se está 
haciendo un progreso real y que se están alcanzando los 
hitos), el control es liviano. Pero cuando aparecen los 
problemas, el gestor debe ejercer el control para solu- 
cionarlos tan pronto como sea posible. Una vez que el 
problema se ha diagnosticado"”, se pueden concentrar 
recursos adicionales en el área del problema: se puede 
redistribuir la plantilla, o se puede redefinir la planifi- 
cación temporal del proyecto. 

Cuando se enfrentan a la presión de una fecha de 
entrega muy ajustada, los gestores de proyecto utilizan 
a veces una planificación temporal de proyecto y una 
técnica de control denominada time-boxing (tiempo 
encajonado) [ZAH95]. Esta estrategla reconoce que qui- 
zás no se pueda entregar el producto completo para la 
fecha límite predefinida. Por tanto, se elige un paradig- 
ma incremental del software (Capítulo 2) y se crea una 
planificación temporal para cada entrega de un incre- 
mento. 

Las tareas asociadas con cada incremento se enca- 
jonan en el tiempo. Esto significa que la planificación 
temporal para cada tarea se ajusta trabajando hacia atrás 
desde la fecha de entrega para cada incremento. Se pone 
una «caja» alrededor de cada tarea. Cuando una tarea 
alcanza el límite de su caja de tiempo (más o menos un 
10 por 100), se termina el trabajo y se empieza la 
siguiente tarea, 

Ea primera reacción frente al enfoque de encajona- 
miento de tiempo es a menudo negativa: «Si no se ha 
terminado el trabajo, ¿cómo podemos proseguir?» La 
respuesta se encuentra en la manera en que se realiza el 
trabajo. Cuando se llega al límite de la caja de tiempo, 
es probable que se haya completado el 90 por 100 de la 
tarea!', El restante 10 por 100, aunque importante, pue- 
de (1) retrasarse hasta el siguiente incremento, o (2) 
completarse más tarde si es necesario. En vez de estar 
«estancado» en una tarea, el proyecto progresa hacia la 
fecha de entrega. 


Ul Un cínico podría recordar el dicho: «El primer 90 por 100 de un sis- 
tema se lleva el 10 por 100 del tiempo. El último 10 por 100 del sistema 
se lleva el 90 por 100 del tiempo.» 
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Terminación 


Tareas de trabajo os Inicio x 
previsto real prevista 

111.1 Identificar necesidades y beneficios 

Reunirse con los clientes Sem 1,d1 Sem 1,d1 Sem 1,d2 

Identificar las necesidades y limitaciones Sem 1,d2 Sem 1,d2 Sem 1,42 

del proyecto 

Establecer la declaración del producto Sem 1,d3 Sem 1,d3 Sem 1,d3 

Hito: declaración de producto definida Sem 1,d3 Sem 1,d3 Sem 1,d3 
11.2 Definir las salidas/control/entradas 

deseadas (SCE) 

Ámbito de las funciones del teclado Sem 1,d4 Sem 1,d4 Sem 2,d2 

Ámbito de las funciones de entrada de voz Sem 1,d3 Sem 1,d3 Sem 2,d2 

Ámbito de los modos de interacción Sem 2,d1 Sem 2,d3 

Ámbito de los diagnósticos del documento Sem 2,d1 Sem 2,d2 

Ámbito de otras funciones WP Sem 1,d4 Sem 1,d4 Sem 2,d3 

Documento SCE Sem 2,d1 Sem 2,d3 

RTF : revisar SCE con el cliente Sem 2,d3 Sem 2,d3 

Revisar SCE según se requiera; Sem 2,d4 Sem 2,d4 

Hito: SCE definido Sem 2,d5 Sem 2,d5 


11,3 Definir ta funcionalidad/comportamiento 


Terminación Personas Esfuerzo Obsérvaciónes 
real asignadas asignado 
Es previsible 
Sem 1,d2 BLS 2 p-d Guereguiera 
Sem 1,d2 JPP 1 p-d más estuerzo/ 
tiempo 
Sem 1,d3 BLS/JPP 1 p-d 
Sem 1,d3 
BLS 1,5 p-d 
JPP 2 p-d 
MLE 1 p-d 
BLS 1,5 p-d 
JPP 2 p-d 
MLL 3 p-d 
Todos 3 p-d 
Todos 3 p-d 


FIGURA 7.5. Un ejemplo de tabla de proyecto. 


En la sección 7.7.2, ya discutimos un número de aproxi- 
maciones cualitativas al seguimiento del proyecto. Cada 
una de ellas proporciona al gestor del proyecto una indi- 
cación del progreso, pero teniendo en cuenta que esta eva- 
luación proporcionada de la información es en cierto modo 
subjetiva, Ahora bien, ¿es razonable preguntarse si exis- 
te una técnica cuantitativa para evaluar el progreso a medi- 
da que el equipo de software avanza a través de las tareas 
de trabajo asignadas en la planificación del proyecto? En 
efecto, una técnica para desarrollar análisis cuantitativo 
del progreso realizado existe. Es denominada análisis de 
valor ganado (AVG). 


El valor ganado proporciona una indicación cuantitativa 
del progreso. 


Humphrey [HUMO95] estudia el valor ganado de la 
manera siguiente: 


El sistema de valor ganado proporciona una escala de valor 
común para cada tarea [proyecto de software], independiente- 
mente del tipo de trabajo que esté siendo Hevado a cabo. Se 
estiman entonces el total de horas para realizar el proyecto com- 
pleto y a cada tarea se le da un valor ganado basado en su por- 
centaje estimado respecto al total. 


Dicho de forma más simple, el valor ganado es una 
medida del progreso. Nos permite evaluar el «porcen- 
taje de realización» de un proyecto utilizando el análi- 
sis cuantitativo más que la opinión particular que de ello 
tengamos. En efecto, Fleming y Koppleman [FLE98] 
aducen que el análisis de valor ganado «proporcionan 
unas lecturas exactas y fiables del desarrollo desde esta- 
dos iniciales como cuando tan sólo se haya realizado un 
15 por ciento del proyecto». 
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Para determinar el valor ganado se desarrollan los 


siguientes pasos: 


l. 


El coste presupuestado del trabajo planificado (CPTP) 
se determina para cada tarea de trabajo que se repre- 
senta en el plan. Durante la actividad de estimación 
(Capítulo 5), el trabajo (en personas-hora, personas- 
día) de cada tarea de ingeniería del software es con- 
venientemente planificada. Por consiguiente, CPTPi 
es el trabajo que se ha planificado para una cierta tarea 
1. Para determinar el progreso en un punto dado a lo 
largo de la planificación del proyecto, el valor de CPTP 
es la suma de los valores CPTPi para todas las tareas 
del trabajo que deberían haber sido completadas en ese 
momento en el plan del proyecto. 


¿Cómo se calcula el valor 
* ganado para evaluar 
el progreso? 


. Los valores CPTP para todas las tareas del trabajo 


se suman para obtener el presupuesto a la termina- 
ción que se denomina PAT. Por consiguiente, 


PAT = Y (CPTP,) para todas las tareas k 


. Acontinuación, se calcula el valor para el coste pre- 


supuestado del trabajo desarrollado (CPTD). El 
valor para CPTD es la suma de los valores CPTP 
para todas las tareas de trabajo que hayan sido real- 
mente terminadas en un punto determinado de la pla- 
nificación del proyecto. 


Wilkens [WIL99] afirma que «la distinción entre el 


CPTP y el CPTD es que el primero representa el pre- 
supuesto de las actividades que estaban planificadas para 
ser completadas, y el último representa el presupuesto 
de las actividades que realmente estaban acabadas». 
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Di A 


Dados los valores para CPTP, PAT, CPTD, pueden ser 
calculados los siguientes indicadores de progreso: 


Índice de desarrollo de planificación, IDP=CPTD/CPTP 
Varianza de la planificación, VP = CPTD — CPTP 


IDP es una indicación de la eficiencia con que el pro- 
yecto está utilizando los recursos de la planificación. 
Un valor IDP cercano a 1.0 indica una ejecución efi- 
ciente de la planificación del proyecto. VP es simple- 
mente una indicación absoluta de la varianza de la 
planificación prevista. 


Porcentaje planificado para terminar = CPTD/PAT 


proporciona una indicación del porcentaje de trabajo 
que debería estar terminado en el instante £. 


Porcentaje completado = CPTP/PAT 


proporciona una indicación cuantitativa del «grado de 
avance en la realización en tanto por ciento» del pro- 
yecto en un instante determinado de tiempo ?. 

Es también posible calcular el coste real de traba- 
jo realizado, CRTR. El valor para CRTR es la suma 
del esfuerzo realmente desarrollado en tareas de tra- 
bajo que hayan sido realizadas en un instante de tiem- 


po de la planificación del proyecto. Es entonces posi- 
ble calcular: 
Índice de desarrollo del coste, IDC = CPTP/CRTR 
Varianza del coste, VC = CPTP - CRTR 


Referencia Web 


Se puede encontrar un gran conjunto de recursos 
pora el análisis del valor ganado (bibliografía completa, 
documentos, enlaces) en www.acq.osd.mil/pm/. 


Un valor de IDC cercano a 1.0 proporciona una Indi- 
cación evidente de que el proyecto está dentro del pre- 
supuesto que para él se ha definido. VC es una indicación 
absoluta de los ahorros en coste (en relación con los cos- 
tes planificados) o de las carencias en una etapa parti- 
cular del proyecto. 

Como ya ocurrió en la aparición del radar, el análi- 
sis del valor ganado aclara las dificultades de planifica- 
ción antes de que ellas puedan aparecer. Esto permite 
al gestor del proyecto de software tomar las acciones 
correctivas adecuadas antes de que la crisis del proyec- 
to estalle. 


A través del proceso de software, un equipo que se dedi- 
ca al proyecto crea productos de trabajo (por ejemplo, 
especificaciones de los requisitos o prototipos, docu- 
mentos de diseño, código fuente). Pero este equipo tam- 
bién crea (y corrige afortunadamente) errores asociados 
con cada producto de trabajo realizado. Si las medidas 
relacionadas con los errores y las métricas resultantes 
son registradas a lo largo de muchos proyectos de soft- 
ware, un gestor de proyectos puede utilizar estos datos 
como una línea base para comparar esto con los datos 
de errores recogidos en tiempo real. El seguimiento del 
error puede utilizarse como una medida para evaluar el 
estado del proyecto actual. 


e 
a 
Y 
CLAVE 
El seguimiento del error nos permite comparar 
el trabajo actual con esfuerzos pasados y proporciona 


una indicación cuantitativa de la calidad del trabajo 
que estemos realizando. 


En el Capítulo 4, el concepto de eficiencia de elimi- 
nación de defectos ya fue discutido. Para recordarlo bre- 
vemente, el equipo de software desarrolla revisiones 
técnicas formales (y, más tarde, comprobaciones) para 
encontrar y corregir los errores, E, en productos realiza- 
dos durante las tareas de ingeniería de software. Cual- 
quiera de los errores que no se hayan descubierto (pero se 
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han encontrado en tareas posteriores) se considera que son 
defectos Hlamados D. La eficiencia de eliminación de 
defectos (Capítulo 4) ha sido definida como: 


EED = ENE+D) 


EED es una métrica de proceso que proporciona una indi- 
cación clara de la efectividad de las actividades de garan- 
tía de calidad, pero EED y el cálculo de errores y defectos 
asociados con ella puede ser también usada para ayudar 
al gestor de proyectos a determinar el progreso que se está 
realizando a medida que el proyecto de software se mue- 
ve a través de las tareas de trabajo planificadas. 
Asumamos que una organización de software ha 
registrado datos de errores y defectos durante los 24 
meses pasados y ha desarrollado promedios para las 
métricas siguientes: 
+ Errores por página de especificación de requisitos, 
Ereq 
+ Errores por componentes a nivel de diseño, Ediseño 
» Errores por componente a nivel de código, Ecodigo 
» EED-análisis de requisitos 
» EED-diseño arquitectónico 
» EED-diseño a nivel de componentes 
+  EED-codificación 
A medida que el proyecto progresa a través de cada 
paso de la ingeniería de software, el equipo de soft- 
ware registra e informa del número de errores encon- 
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trados en los requisitos, diseño y revisiones de códi- 
go. El gestor del proyecto calcula los valores actua- 
les para Ereg, Ediseño y Ecodigo. Estos son después 
comparados con los promedios de proyectos anterio- 
res. Si los resultados actuales discrepan en más de un 
20 por 100 de dicho promedio, ello puede ser causa 
de preocupación, y debe ser objeto de una investiga- 
ción posterior. 


Cons: 


Cuanto más cuantitativo sea su enfoque pora el 
seguimiento y control del proyecto, estará probablemente 
más preparado para prevenir problemas potenciales y 
responder ante ellos de un modo proactivo. Utilice 
métricas de seguimiento y de valor ganado. 


Por ejemplo, si Ereq =2.1 en el proyecto X, y el pro- 
medio de la organización es 3.6, es posible uno de estos 
dos escenarios: (1) que el equipo de software haya desa- 
rrollado el trabajo preferente de desarrollar las especi- 
ficaciones de requisitos o (2) que el equipo haya prestado 
una atención secundaria en la aproximación a la revi- 


ECT: 


Cada paso en el proceso de ingeniería del software debe- 
ría obtener una entrega que pueda revisarse y que pueda 
hacer de fundamento para los siguientes pasos. El Plan 
del Proyecto de Software se produce a la culminación de 
las tareas de planificación. Proporciona información bási- 
ca de costes y planificación temporal que será empleada 
alo largo del proceso de software, 

El Plan del Proyecto de Software es un documento 
relativamente breve dirigido a una audiencia diversa. 
Debe (1) comunicar el ámbito y recursos a los gestores 
del software, personal técnico y al cliente; (2) definir 
los riesgos y sugerir técnicas de aversión al riesgo; (3) 
definir los costes y planificación temporal para la revi- 
sión de la gestión; (4) proporcionar un enfoque general 
del desarrollo del software para todo el personal rela- 


La planificación temporal es la culminación de una acti- 
vidad de planificación, componente primordial de la 
dirección de proyectos de software. Cuando se combi- 
nan métodos de estimación y análisis de riesgo, la pla- 


PLANIFICACION TEMPORAL Y SEGUIMIENTO DEL PRODUCTO 


sión. Si el segundo escenario parece más probable, el 
gestor de proyecto debería adoptar los pasos necesarios 
para construir un tiempo** de diseño adicional dentro 
del plan con el fin de acomodar los defectos de requisi- 
tos que probablemente hayan podido propagarse a tra- 
vés de la actividad propia de diseño. 

La métrica de seguimiento de errores descrita ante- 
riormente puede ser utilizada también para los recur- 
sos de comprobación y/o revisión de objetivos. Por 
ejemplo, si un sistema se compone de 120 compo- 
nentes, pero 32 de dichos componentes muestran valo- 
res Ediseño que tengan una varianza sustancial a partir 
del promedio, el gestor del proyecto puede elegir dedi- 
car recursos de revisión de código a los 32 compo- 
nentes y permitir a otros pasar a su comprobación con 
una revisión de código. Aunque todos los componen- 
tes deberían ser sometidos a una revisión de código en 
una supuesta revisión ideal, para los proyectos que se 
hayan pasado de presupuesto puede ser un medio efec- 
tivo realizar una aproximación selectiva (revisando 
sólo aquellos módulos que tengan una calidad dudosa 
basándose en el valor diseño) con el fin de recupe- 
rar el tiempo perdido y/o ahorrar los costes. 


cionado con el proyecto, y (5) describir cómo se garan- 
tizará la calidad y se gestionan los cambios. 


Plan del Proyecto de Software 


DOCUMENTO 


Es importante señalar que el Plan del Proyecto del Soft- 
ware no es un documento estático. Esto es, el equipo del 
proyecto consulta el plan repetidamente —actualizando 


riesgos, estimaciones, planificaciones e información rela- 


cionada— a la vez que el proyecto avanza y es más cono- 


cido. 


de 


casas 


nificación temporal se convierte en un mapa de carre- 
teras a seguir por el gestor del proyecto. 


La planificación temporal empieza con la des- 


composición del proceso. Las características del pro- 


12 En realidad, el tiempo extra será gastado en volver a trabajar en 


los defectos de requisitos, pero este trabajo tendrá lugar cuando se 
emprenda el trabajo de diseño. 
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yecto se emplean para adaptar un conjunto de tare- 
as apropiado al trabajo a realizar. Una red de tareas 
muestra todas las tareas de ingeniería, sus depen- 
dencias con otras tareas y sus duraciones previstas. 
La red de tareas se usa para calcular el camino crí- 


tico del proyecto, un gráfico de tiempo e informa- 
ción diversa del proyecto. El gestor del proyecto pue- 
de seguir y controlar todos los pasos del proceso de 
software usando la planificación temporal como 
directriz. 


[BR095] Brooks, M., The Mythical Man-Month, ed. Aniver- 
sario, Adison-Wesley, 1995, 


[FLE98] Fleming, Q.W., y J.M. Koppelman, «Earned Value 
Project Management», Crosstalk, vo1.11,n.27, Julio 1998, 
p. 19. 


[HUMO95] Humphrey, W., A Discipline for Software Engine- 
ering, Addison-Wesley, 1995. 


[MOD83] Moder, J. J., C. R. Philips y E. W. Davis, Pro- 
ject Management with CPM, PERT and Precedence Dia- 
gramming, 32 ed., VanNostrad Reinhold, 1983. 


[PAG85] Page-Jones, M., Practical Project Management, 
Dorset House, 1985, pp. 90-91. 


[PRE99] Pressman, R. S., Adaptable Process Model, R. S. 
Pressmand Associates, 1999, 


[PUT92] Putman, L., y W. Myers, Measures for Excellence, 
Yourdon Press, 1992. 


[RIGS 1] Riggs, J., Production Systems Planning, Analysis 
and Control, 3% ed., Wiley, 1981. 


[THE93] Thé, L., «Project Management Software That's IS 
Friendly», Datamation, Octubre 1993, pp. 55-58. 


[WIL99] Wilkens, T.T., «Earned Value, Clear and Simple», 
Primavera Systems, Inc, Abril 1999, p. 2. 


[ZAH95] Zahniser, R., «Time-boxing for Top Team Perfor- 
mance», Software Development, Marzo 1995, pp. 34-38. 


7.1. Las fechas límite «irracionales» son un hecho consuma- 
do del negocio del software. ¿Cómo procedería si se encuen- 
tra en esta situación? 


7.2, ¿Cuál es la diferencia entre una planificación temporal 
macroscópica y una detallada? ¿Es posible dirigir un proyec- 
to si sólo se desarrolla una planificación temporal macroscó- 
pica? ¿Por qué? 


7.3. ¿Hay algún caso en el que un hito de un proyecto no está 
sujeto a una revisión? Si es así, proporcione uno o más ejem- 
plos. 


7.4, En la Sección 7.2.1, se presenta un ejemplo de «sobre- 
carga de comunicaciones» que puede ocurrir cuando mucha 
gente trabaja en un proyecto de software. Desarrolle un 
ejemplo que ilustre cómo unos ingenieros expertos, y con 
buenas experiencias en ingeniería del software y que utili- 
zan revisiones técnicas formales, pueden mejorar el ritmo 
de producción de un equipo (comparado con la suma de los 
ritmos individuales de producción). Pista: puede asumir que 
las revisiones reducen el retrabajo y que estas repeticiones 
del trabajo suponen de un 20 a un 40 por 100 del tiempo 
de una persona. 


7.5. Aunque agregar gente a un proyecto atrasado lo puede 
retrasar aún más, hay circunstancias en las que no es verdad. 
Descríbalas. 
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7.6. La relación entre el personal y el tiempo no es lineal. 
Usando la ecuación del software de Putman (descrita en la 
Sección 7.2.2), desarrolle una tabla que relacione el núme- 
ro de gente con la duración del proyecto para un proyecto 
de software que requiera 50.000 LDC y 15 personas-año 
de esfuerzo (el parámetro de productividad es 5.000 y 
B = 0,37). Asuma que el software debe entregarse en 24 
meses, más/menos 12 meses. 


7.7. Asuma que ha sido contratado por una universidad para 
desarrollar un sistema interactivo para apuntarse a Cursos 
(OLCRS). Primero, actúe como el cliente (¡si usted es un estu- 
diante, le resultará fácil!) y especifique las características de 
un buen sistema. [Alternativamente, su profesor le propor- 
cionará un conjunto de requisitos preliminares para el sistema.] 
Usando los métodos de estimación estudiados en el Capítulo 
5, desarrolle una estimación de esfuerzo y duración para un 
OLCRS. Sugiera cómo: 


a) definiría las actividades paralelas de trabajo durante el pro- 
yecto OLCRS; 
b) distribuiría el esfuerzo a lo largo del proyecto; 


c) establecería hitos para el proyecto. 


7.8. Usando la Sección 7.3 como directriz, calcule el SCT 
para OLCRS. Asegúrese de mostrar todo su trabajo. Selec- 
cione un tipo de proyecto y cree un conjunto apropiado de 
tareas para el proyecto. 
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7.9. Defina una red de tareas para OLCRS o, alternativamente, 
para otro proyecto de software que le interese. Asegúrese de 
mostrar las tareas e hitos y adjuntar las estimaciones de 
esfuerzo y tiempo para cada tarea. Si es posible, utilice una 
herramienta de programación automática para realizar este 
trabajo. 


7.10. Si dispone de una herramienta de programación auto- 
mática, determine el camino crítico para la red definida en el 
problema 7.9. 


7.11. Usando una herramienta de programación automática (si 
es posible) o papel y lápiz (si es necesario), desarrolle un grá- 
fico de tiempo para el proyecto OLCRS. 


7.12, Refine la tarea denominada evaluación del riesgo tec- 
nológico en la sección 7.4 del mismo modo que se refinó el 
ámbito del concepto en la Sección 7.5. 


7.13. Suponga que es un gestor de proyectos de software y 
que se le ha pedido que calcule estadísticas del valor gana- 
do para un proyecto de software sencillo. El proyecto tiene 
56 tareas planificadas que se estima que necesiten 582 per- 
sonas-día para realizarlas. Al tiempo que ha sido solicitado 
para realizar el análisis del valor ganado, se han completa- 
do 12 tareas. Sin embargo, la planificación temporal del pro- 
yecto indica que se deberían haber completado 15 tareas. 
Están disponibles los siguientes datos de planificación (en 
personas-día): 


OTRAS LECTURAS Y FUENTES DE 


McConnel (Rapid Development, Microsoft Press, 1996) 
presenta un estudio excelente acerca de los aspectos que con- 
ducen a una planificación de proyectos de software demasia- 
do optimista y lo que se puede hacer con ella. O”"Connell (How 
to Run Successful Projects H:The Silver Bullet, Prentice Hall, 
1997) presenta un enfoque paso a paso para la gestión de pro- 
yectos que pueden ayudarle a desarrollar una planificación 
temporal realista para sus proyectos. 


Los aspectos de la planificación temporal están cubier- 
tos en la mayoría de los libros sobre gestión de proyectos 
de software. McConnell (Software Project Survival Gui- 
de, Microsoft Press, 1998), Hoffman y Beaumont (Appli- 
cation Development: Managing a Project's Life Cycle, 
Midrange Computing, 1997), Wysoki y sus colegas (Effec- 
tive Project Management, Wiley, 1995) y Whitten (Mana- 
¿ing Software Development Projects, 2.2 ed., Wiley, 1995) 
consideran el tema en detalle. Boddie (Crunch Mode, Pren- 
tice-Hall, 1987) han escrito un libro para todos los gesto- 
res que «tienen 90 días para hacer un proyecto de seis 
meses». 


INFORMACIÓN 
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tarea esfuerzo planificado esfuerzo real 
1 12,0 12,5 
2 15,0 11,0 
3 13,0 17,0 
4 8,0 9,5 
5 9,5 9.0 
6 18,0 19,0 
7 10,0 10,0 
8 4,0 4,5 
9 12,0 10,0 
110) 6,0 6,5 
11 5,0 4,0 
12 14,0 14,5 
13 16,0 - 
14 6,0 - 
15 8,0 - 


Calcule IDP, la varianza de la planificación, el porcentaje pla- 
nificado para terminación, el porcentaje completo IDC y la 
varianza del coste para el proyecto. 


7.14. Es posible utilizar EED como una métrica para el 
seguimiento de errores en un proyecto de software. Estu- 
die los pros y los contras de utilizar EED para este propó- 
sito. 


También se puede obtener información que merece la pena 
en los libros de gestión de proyectos de propósito general. 
Entre ellos se encuentran: 


Kezner, H., Project Management: A Systems Approach to 
Planning, Scheduling, and Controlling, Wiley, 1998. 


Lewis, J. P., Mastering Project Management: Applying 
Advanced Concepts of Systems Thinking, Control and Eva- 
luation, McGraw-Hill, 1988. 


Fleming y Koppelman (Earned Value Project Manage- 
ment, Project Management Institute Publications, 1996) tra- 
tan con mucho detalle el uso de técnicas de valor ganado para 
el seguimiento y control de proyectos. 

En Internet están disponibles una gran variedad de fuentes 
de información relacionadas con temas de gestión y planifica- 
ción temporal de proyectos. Se puede encontrar una lista actua- 
lizada con referencias a sitios (páginas) web que son relevantes 
para la planificación en http://www.pressman5.com. 
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CAPÍTULO 


GARANTÍA DE CALIDAD 
DEL SOFTWARE (SQA/GCS)* 


L enfoque de ingeniería del software descrito en este libro se dirige hacia un solo obje- 
tivo: producir software de alta calidad. Pero a muchos lectores les inquietará la pregunta: 
«¿Qué es la calidad del software?» 

Philip Crosby [CRO079], en su famoso libro sobre calidad, expone esta situación: 


El problema de la gestión de la calidad no es lo que la gente no sabe sobre ella. El problema es lo que 
creen que saben... 

A este respecto, la calidad tiene mucho en común con el sexo. Todo el mundo lo quiere. (Bajo ciertas 
condiciones, por supuesto.) Todo el mundo cree que lo conoce. (Incluso aunque no quiera explicarlo.) Todo 
el mundo piensa que su ejecución sólo es cuestión de seguir las inclinaciones naturales. (Después de todo, 
nos las arreglamos de alguna forma.) Y, por supuesto, la mayoría de la gente piensa que los problemas en 
estas áreas están producidos por otra gente. (Como si sólo ellos se tomaran el tiempo para hacer las cosas 
bien.) 


Algunos desarrolladores de software continúan creyendo que la calidad del software es algo 
en lo que empiezan a preocuparse una vez que se ha generado el código. ¡Nada más lejos de la 
realidad! La garantía de calidad del software (SQA, Software Quality Assurance GCS, Gestión 
de calidad del software) es una actividad de protección (Capítulo 2) que se aplica a lo largo de 
todo el proceso del software. La SQA engloba: (1) un enfoque de gestión de calidad; (2) tee- 
nología de ingeniería del software efectiva (métodos y herramientas); (3) revisiones técnicas 
formales que se aplican durante el proceso del software; (4) una estrategia de prueba multies- 
calada; (5 Jel control de la documentación del software y de los cambios realizados; (6) un pro- 
cedimiento que asegure un ajuste a los estándares de desarrollo del software (cuando sea posible), 
y (7) mecanismos de medición y de generación de informes. 

En este capítulo nos centraremos en los aspectos de gestión y en las actividades específicas 
del proceso que permitan a una organización de software asegurar que hace «las cosas correc- 
tas en el momento justo y de la forma correcta». 


VISTAZO RÁPIDO 


mé es? No es suficiente hablar por 
hablar diciendo que la calidad del soft- 
are.es importante, tienes que: (1) defi- 
nir explícitamente lo que significa 


o de actividades que ayuden -a 
garantizar que todo producto de lainge- 


'niería del software presenta alta cali-" 
'dad: (3) llevara cabo actividades de 
intía de calidad en cada proyecto de. 
ftware; 4) utilizar métricas para desa- 


er estrategias que mejoren el pro- 


so del software y, como consecuencia, 
ejoren lá calidad del producto final. 


ace? Todo el que esté rela- de 


oñado con el proceso de ingeniería 


' qué es E Lo ces 
cer correctamente o lo. puedes 


«calidad del software»; (2) crear un con- 


ftware e es A de la cali- de 


repetir. Si un equipo de software apli- 
ca la talidad a todas las actividades 
de la ingeniería del software, reduci- 
rá la cantidad de trabajo repetido que 
deba realizar. Esto supondrá costes 
más bajos y, lo que es más importan- 
te, mejorará el tiempo de llegada al 
mercado. 


.. ¿Cuáles son los pasos? Antes de que 


se puedan iniciar las actividades de 
garantía de calidad del software, es 
importante definir la «calidad del soft- 
ware» a un número diferente de nive- 
les de. abstracción. Una vez que 
comprendes lo que es la calidad, un 


equipo de software debeidentificar un ' 


conjunto de actividades de garantía de 
calidad del software que eliminarán 
los errores de los productos realizados 
antes de que ocurran. 


¿Cuál es el producto obtenido? Para 
definir una estrategia de SQÁ para el 
equipo de software se ha creado un 
plan de garantía de calidad del soft- 
ware. Durante el análisis, diseño y 
codificación, el producto principal de 
'SQA es un breve informe de la revisión 
técnica formal. Durante las pruebas, se 
realizan los planes y procedimientos 
de prueba. También se pueden gene- 
rar otros productos de trabajo relacio- 
nados con la mejora del proceso. 


¿Cómo puedo asegurar que lo he 
hecho correctamente? Encontrar los 
errores antes que pasen a ser defectos!. 
Esto es, trabajar para mejorar tu eficien- 
cia en la eliminación de errores (Capí- 
tulos 4 y 7), reduciendo de este modo la 
cantidad de trabajo repetido que tiene 
que hacer tu equipo de software. 


* N. del T.: En español, GCS. Se conservan las siglas SQA en inglés por estar muy extendido su uso para la jerga infor- 
mática. A veces se suelen traducirestas siglas también por «Aseguramiento de la Calidad del Software». 
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Se dice que dos copos de nieve no son iguales. Cierta- 
mente cuando se observa caer la nieve, es difícil ima- 
ginar que son totalmente diferentes, por no mencionar 
que cada copo posee una estructura única. Para obser- 
var las diferencias entre los copos de nieve, debemos 
examinar los especímenes muy de cerca, y quizá con 
un cristal de aumento. En efecto, cuanto más cerca los 
observemos, más diferencias podremos detectar. 

Este fenómeno, variación entre muestras, se aplica 
atodos los productos del hombre asícomo a la creación 
natural. Por ejemplo, si dos tarjetas de circuito «idénti- 
cas» se examinan muy de cerca, podremos observar que 
las líneas de cobre sobre las tarjetas difieren ligeramente 
en la geometría, colocación y grosor. Además, la loca- 
lización y el diámetro de los orificios de las tarjetas tam- 
bién varían. 


ómo de rápido hiciste un trabajo- 
cómo de bien lo hiciste. 


El control de variación es el centro del control de 
calidad. Un fabricante quiere reducir la variación entre 
los productos que se fabrican, incluso cuando se reali- 
za algo relativamente sencillo como la duplicación de 
disquetes. Seguramente, esto puede no ser un problema 
—la duplicación de disqueteses una operación de fabri- 
cación trivial y podemos garantizar que se crean dupli- 
cados exactos de software —. 

¿Podemos?. Necesitamos asegurar que las pistas se 
sitúen dentro de una tolerancia específica para que la 
gran mayoría de las disqueteras puedan leer los dis- 
quetes. Además, necesitamos asegurar que el flujo mag- 
nético para distinguir un cero de un uno sea suficiente 
para que los detecten las cabezas de lecturafescritura. 
Las máquinas de duplicación de discos aceptan orecha- 
zan la tolerancia. Por consiguiente, incluso un proceso 
«simple», como la duplicación, puede encontrarse con 
problemas debidos a la variación entre muestras. 


Yi 
a 


CLAVE 


Controlar la variación es la clave de un producto de alta 
calidad. En el contexto del software, nos esforzamos 
en controlarla variación en el proceso que aplicamos, 
recursos que consumimosy los atributos de calidad 

del productofinal. 


1 Esta sección, escrita por Michael Ctovcky, se ha adaptado de <(Fun- 
damentals of ICO 9000», un libro de trabajo desarrollado para Essen- 
tial Software Engineering, un vídeo curriculum desarrollado por R.S. 
Pressmané:Asociados, Inc. Reimpresión autorizada. 
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¿Cómo se aplica esto al software? ¿Cómo puede 
una organización de desarrollo de software necesitar 
controlar la variación? De un proyecto a otro, quere- 
mos reducir la diferencia entre los recursos necesa- 
rios planificados para terminar un proyecto y los 
recursos reales utilizados, entre los que se incluyen 
personal, equipo y tiempo. En general, nos gustaría 
asegurarnos de que nuestro programa de pruebas abar- 
ca un porcentaje conocido del software de una entre- 
ga a otra. No sólo queremos reducir el número de 
defectos que se extraen para ese campo, sino también 
nos gustaría asegurarnos de que los errores ocultos 
también se reducen de una entrego a otra. (Es proba- 
ble que nuestros clientes se molesten si la tercera 
entrega de un producto tiene diez veces más defectos 
que la anterior.) Nos gustaría reducir las diferencias 
en velocidad y precisión de nuestras respuestas de 
soporte a los problemas de los clientes. La lista se 
podría ampliar más y más. 


8.1.1. Calidad 


El American Heritage Dictionary, define la calidad como 
«una característica o atributo de algo». Como un atri- 
buto de un elemento, la calidad se refiere a las caracte- 
rísticas mensurables —cosas que se pueden comparar 
con estándares conocidos como longitud, color, propie- 
dades eléctricas, maleabilidad, etc,—. Sin embargo, el 
software en su gran extensión, como entidad intelectual, 
es más difícil de caracterizar que los objetos físicos. 

No obstante, sí existen las medidas de característi- 
cas de un programa. Entre estas propiedades se inclu- 
yen complejidad ciclomática, cohesión, número de 
puntos de función, líneas de código y muchas otras estu- 
diadas en los Capítulos 19y 24. Cuando se examina un 
elemento según sus características mensurables, se pue- 
den encontrar dos tipos de calidad: calidad del diseño 
y calidad de concordancia. 


La calidad de diseño se refiere a las características 
que especifican los ingenieros de software para un ele- 
mento. El grado de materiales, tolerancias y las especi- 
ficaciones del rendimiento contribuyen a la calidad del 
diseño. Cuando se utilizan materiales de alto grado y se 
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especificantolerancias más estrictas y niveles más altos 
de rendimiento, la calidad de diseño de un producto 
aumenta, si el producto se fabrica de acuerdo con las 
especificaciones. 

La calidad de concordancia es el grado de cumpli- 
miento de las especificaciones de diseño durante su rea- 
lización. Una vez más, cuanto mayor sea el grado de 
cumplimento, más alto será el nivel de calidad de con- 
cordancia. 

En el desarrollo del software, la calidad de diseño 
comprende los requisitos, especificaciones y el diseño 
del sistema. La calidad de concordancia es un aspecto 
centrado principalmente en la implementación. Si la 
implementación sigue el diseño, y el sistema resultan- 
te cumple los objetivos de requisitos y de rendimiento, 
la calidad de concordancia es alta. 

Pero, ¿son la calidad del diseño y la calidad de 
concordancia los Únicos aspectos que deben consi- 
derar los ingenieros de software? Robert Glass 
[GLA98] establece para ello una relacion más «intui- 
tiva»: 

satisfacción del usuario =productosatisfactorio+buena cali- 


dad+ entrega dentro de presu- 
puesto y del tiempo establecidos 


En la última línea, Glass afirma que la calidad es impor- 
tante, pero si el usuario no queda satisfecho, ninguna otra 
cosarealmente importa. DeMarco [DEMO99] refuerza este 
punto de vista cuando afirma: «La calidad del producto 
es una función de cuánto cambia el mundo para mejor.» 
Esta visión de la calidad establece que si el producto de 
software proporciona un beneficio sustanciala los usua- 
nos finales, pueden estar dispuestos para tolerar proble- 
mes ocasionales del rendimientoo de fiabilidad. 


8.12, Control de calidad 


El control de cambios puede equipararse al control de 
calidad. Pero, ¿cómo se logra el control de calidad? El 
control de calidad es una serie de inspecciones, revi- 
siones y pruebas utilizados a lo largo del proceso del 
software para asegurar que cada producto cumple con 
los requisitos que le han sido asignados. El control de 
calidad incluye un bucle de realimentación (feedback) 
del proceso que creó el producto. La combinación de 
medición y realimentación permite afinar el proceso 
cuando los productos de trabajo creados fallan al cum- 
plir sus especificaciones. Este enfoque ve el control de 
calidad como parte del proceso de fabricación. 


$ ¿Qué es el control de calidad 
del software? 


Las actividades de control de calidad pueden ser 
manuales, completamente automáticas o una combi- 
nación de herramientas automáticas e interacción 
humana. Un concepto clave del control de calidad es 
que se hayan definido todos los productos y las espe- 
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cificaciones mensurables en las que se puedan com- 
parar los resultados de cada proceso. El bucle de rea- 
limentación es esencial para reducir los defectos 
producidos. 


8.1.3. Garantía d e calidad 


La garantia de calidad consiste en la auditoría y las fun- 
ciones de información de la gestión. El objetivo de la 
garantíade calidad es proporcionarla gestión para infor- 
mar de los datos necesarios sobre la calidad del pro- 
ducto, por lo que se va adquiriendo una visión más 
profunda y segura de que la calidad del producto está 
cumpliendosus objetivos. Por supuesto, si los datos pro- 
porcionados mediante la garantía de calidad identifican 
problemas, es responsabilidad de la gestión afrontar los 
problemas y aplicar los recursos necesarios para resol- 
ver aspectos de calidad. 


Se puede encontrar una gran variedad de recursos de 
calidad del software en 
www.qualitytree.com/links /links.htm 


8.1.4. Coste de calidad 


El coste de calidad incluye todos los costes acarreados 
en la búsqueda de la calidad o en las actividades rela- 
cionadas en la obtención de la calidad. Se realizan estu- 
dios sobre el coste de calidad para proporcionar una línea 
base del coste actual de calidad, para identificaroportu- 
nidades de reducir este coste, y para proporcionar una 
base normalizada de comparación. La base de normali- 
zación siempre tiene un precio. Una vez que se han nor- 
malizado los costes de calidad sobre un precio base, 
tenemos los datos necesarios para evaluar el lugar en 
donde hay oportunidades de mejorar nuestros procesos. 
Es más, podemos evaluar cómo afectan los cambios en 
términos de dinero. 

Los costes de calidad se pueden dividir en costes 
asociados con la prevención, la evaluación y los fallos. 
Entre los costes de prevención se incluyen: 


+ planificación de la calidad, 

+ revisiones técnicas formales, 
+ equipo de pruebas, 

- formación. 


¿Cuáles son 
los componentes 
del coste de calidad? 


Entre los costes de evaluación se incluyen activida- 
des para tener una visión más profunda de-la condición 
del producto «la primera vez a través de» cada proce- 
so. A continuación se incluyen algunos ejemplos de cos- 
tes de evaluación: 
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+ Inspección en el proceso y entre procesos, 
+ Calibrado y mantenimiento del equipo, 


» pruebas. 


Consuo 


Ne tengo miedo de incurrir en costes significativos 
de prevención. Esté segura de que su inversión 
le proporcionaráun beneficio excelente. 


Los costes defallos son los costes que desapare- 
cerían si no surgieran defectos antes del envío de un 
producto a los clientes. Estos costes se pueden sub- 
dividir en costes de fallos internos y costes de fallos 
externos. Los internos se producen cuando se detec- 
ta un error en el producto antes de su envío. Entre 
estos se incluyen: 


+ retrabajo (revisión), 
» reparación, 
+ análisis de las modalidades de fallos. 


Los costes defallos externos son los que se asocian 
a los defectos encontrados una vez enviado el produc- 
to al cliente. A continuación se incluyen algunos ejem- 
plos de costes de fallos externos: 


+ resolución de quejas, 

. devolución y sustitución de productos, 
+ Soporte de línea de ayuda, 

+ trabajo de garantía. 


Como es de esperar, los costes relativos para encon- 
trar y reparar un defecto aumentan dramáticamente a 
medida que se cambia de prevención a detección y des- 
de el fallo interno al externo. La Figura 8.1, basada en 
datos recopilados por Boehm [BOE381], ilustra este fenó- 


meno. 
Conse) 


las pruebas son necesarías, pero también 

es una formacostosa deencontrar errores. Gaste 

el tiempo en encontrar errores al comienzo del proceso 
y podrá reducirsignificafivamente los costes de pruebas 
y depuración. 


Kaplan y sus colegas [KAP95] refuerzan las esta- 
dísticas de costes anteriores informandocon datos anec- 
dóticos basados en un trabajo realizado en las 
instalaciones de desarrollo de IBM en Rochester: 


Se han dedicado 7.053 horas inspeccionando 200.000 lí- 
neas de código con el resultado de 3.112 errores potenciales 
descubiertos. Dando por sentado un coste de programador de 
40 dólares por hora, el coste de eliminar 3.1 12 defectos ha sido 
de 282.120 dólares, o aproximadamente unos 91 dólares por 
defecto. 


Compare estos números con el coste de eliminación de 
defectos una vez que el producto se ha enviado al cliente. 
Suponga que no ha habido inspecciones, pero que los progra- 
madores han sido muy cuidadosos y solamente se ha escapa- 
do un defecto por 1.000 líneas de código [significativamente 
mejor que la media en industrial] en el producto enviado. Eso 
significaría que se tendrían que corregir todavía 200 defectos 
en la casa del cliente o después de la entrega. A un coste esti- 
mado de 25.000 dólares por reparaciónde campo, el coste sena 
de 5 millones de dólares, o aproximadamente 18 veces más 
caro que el coste total del esfuerzo de prevención de defectos. 


40-1000 


1000 
1 veces 


100 


10 


Coste relativo de corregir un error 


Requisitos Diseño Código Prueba Prueba Enfase de 


de de explotación 
desarrollo sistema 


FIGURA 8.1. Coste relativo de corregir un error. 


Es verdad que IBM produce software utilizado por 
cientos de miles de clientes y que sus costes por repa- 
ración en casa del cliente o después de la entrega pue- 
den ser más altos que los de organizaciones de software 
que construyen sistemas personalizados. Esto, de nin- 
guna manera, niega los resultados señalados anterior- 
mente. Aunque la organización media de software tiene 
costes de reparación después de la entrega que son el 
25 por 100de los de IBM (¡la mayoría no tienen ni idea 
de cuales son sus costes!), se están imponiendo ahorros 
en el coste asociados con actividades de garantía y con- 
trol de calidad. 


Hoy en día los responsables expertos de compañías de 
todo el mundo industrializado reconocen que la alta cali- 
dad del producto se traduce en ahorro de coste y en una 
mejora general. Sin embargo, esto no era siempre el caso. 


La tendencia de la calidad comenzóen los años cuarenta 


con el influyente trabajo de W. Edwards Deming 
[DEM86], y se hizo la primera verificación en Japón. 
Mediante las ideas de Deming como piedra angular, los 
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japoneses han desarrolladoun enfoque sistemático para 
la eliminación de las causas raíz de defectos en produc- 
tos. A lo largo de los años setenta y ochenta, su trabajo 
emigró al mundo occidental y a veces se llama «gestión 
total de calidad (GTC)»”. Aunque la terminología difiere 
según los diferentes países y autores, normalmente se 
encuentrauna progresión básica de cuatro pasos que cons- 
tituye el fundamento de cualquierprograma de GTC. 


Ke » 
CLA VE 


Se puede aplicar GTC al software de computadora. 
El enfoque GTC se centra en la mejora continua 
del proceso. 


El primer paso se llama kuizen y se refiere a un sis- 
tema de mejora continua del proceso. El objetivo de ka:- 
zen es desarrollar un proceso (en este caso, proceso del 
software) que sea visible, repetible y mensurable. 

El segundo paso, invocado sólo una vez que se ha 
alcanzado kuizen, se llama aturimae hinshitsu. Este paso 
examina lo intangible que afecta al proceso y trabaja 
para optimizar su impacto en el proceso. Por ejemplo, 
el proceso de software se puede ver afectado por la alta 
rotación de personal que ya en sí mismo se ve afectado 
por reorganizaciones dentro de una compañía. Puede 
ser que una estructura organizativa estable haga mucho 
para mejorar la calidad del software. Atarimae hinshit- 
su llevaría a la gestión a sugerir cambios en la forma en 
que ocurre la reorganización. 


$ 


Hasta el desarrollador de software más agobiado esta- 
rá de acuerdo con que el software de alta calidad es una 
meta importante. Pero, ¿cómo definimos la calidad? Un 
bromista dijo una vez: «Cualquier programa hace algo 
bien, lo que puede pasar es que no sea lo que nosotros 
queremos que haga». 


En los libros se han propuesto muchas definiciones 
«Szcalidad del software. Por lo que a nosotros respecta, 
Ta calidad del software se define como: 


¿Cómo se define «calidad 
del software)? 


Concordancia con los requisitos funcionales y de rendi- 
mientoexplícitamente establecidos,con los estándaresde desa- 
rrollo explícitamente documentados, y con las características 
implícitas que se espera de todo software desarrollado profe- 
sionalmente. 


No hay duda de que la anterior definición puede ser 
modificada o ampliada. De hecho, no tendría fin una dis- 
cusión sobre una definición formal de calidad del soft- 


2 Consulte [ART92] para un estudio más completo del GTC y su uso 
enun contexto de software, y [KAP95] para un estudio sobre el uso 
de criterio «Balbridge Award» en el mundo del software. 


ESE 
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Mientras que los dos primeros pasos se centran en 
el proceso, el paso siguiente llamado kansei (traducido 
como «los cinco sentidos») se centra en el usuario del 
producto (en este caso, software). En esencia, exami- 
nando la forma en que el usuario aplica el producto, 
kunsei conduce a la mejora en el producto mismo, y 
potencialmente al proceso que lo creó. 

Finalmente, un paso llamado miryokuteki hinshitsu 
amplía la preocupación de la gestión más allá del pro- 
ducto inmediato. Este es un paso orientado a la gestión 
que busca la oportunidad en áreas relacionadas que se 
pueden identificar observando la utilización del pro- 
ducto en el mercado. En el mundo del software, mirvo- 
kuteki hinshitsu se podría ver como un intento de 
detectar productos nuevos y beneficiosos, o aplicacio- 
nes que sean una extensión de un sistema ya existente 
basado en computadora. 


Referencia Web 


Se puede encontrar una gran variedad de recursos 
poro la mejora continua del proceso y GTC en 
deming.eng.clemsom.edu/ 


Para la mayoría de las compañías, kuizen debería 
ser de preocupación inmediata. Hasta que se haya logra- 
do un proceso de software avanzado (Capítulo 2), no 
hay muchos argumentos para seguir con los pasos 
siguientes. 


dd 


ware. Para los propósitos de este libro, la anterior defini- 
ción sirvepara hacer hincapié en tres puntos importantes: 


1. Los requisitos del software son la base de las medi- 
das de la calidad. La falta de concordancia con los 
requisitos es una falta de calidad. 

. Los estándares especificados definen un conjunto de 
criterios de desarrollo que guían la forma en que se 
aplica la ingeniería del software. Sino se siguen esos 
criterios, casi siempre habrá falta de calidad. 

. Existe un conjunto de requisitos implícitos que a 
menudo no se mencionan (por ejemplo: el deseo por 
facilitar el uso y un buen mantenimiento). Si el soft- 
ware se ajusta a sus requisitos explícitos pero falla 
en alcanzar los requisitos implícitos, la calidad del 
software queda en entredicho. 


8.3.1. Problemas de fondo 

La historia de la garantía de calidad en el desarrollo de 
softwarees paralela a la historia de la calidaden la crea- 
ción de hardware. Durante los primeros años de la infor- 
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mática (los años cincuenta y sesenta), la calidad era res- 
ponsabilidad únicamente del programador. Durante los 
años setenta se introdujeron estándares de garantía de 
calidad para el software en los contratos militares para 
desarrollo de software y se han extendido rápidamente 
a los desarrollos de software en el mundo comercial 
[IEE94]. Ampliando la definición presentada anterior- 
mente, la garantía de calidad del software (SQA) es un 
«patrón de acciones planificado y sistemático»[SCH97] 
que se requiere para asegurar la calidad del software. El 
ámbito de la responsabilidad de la garantía de calidad se 
puede caracterizarmejor parafraseandoun popular anun- 
cio de coches: «La calidad es la 1? tarea.» La implica- 
ción para el software es que muchos de los que 
constituyen una organización tienen responsabilidad de 
garantía de calidad del software —ingenierosde soft- 
ware, jefes de proyectos, clientes, vendedores, y aque- 
llas personas que trabajan dentro de un grupo de SQA— 


Referencia 


Se puede encontrar un tutorial profundo y amplios 
recursos para la gestión de calidad en 
Wwww.management.gov 


El grupo de SQA sirve comorepresentación del clien- 
te en casa. Es decir, la gente que lleva a cabo'la SQA 
debe mirar el software desde el punto de vista del clien- 
te. ¿Satisface de forma adecuada el software los facto- 
res de calidad apuntados en el Capítulo 197 ¿Se ha 
realizado el desarrollo del softwarede acuerdo con están- 
dares preestablecidos? ¿Han desempeñado apropiada- 
mente sus papeles las disciplinas técnicas como parte 
de la actividad de SQA? El grupo de SQA intenta res- 
ponder a estas y otras preguntas para asegurar que se 
mantiene la calidad del software. 


8.3.2. Actividades de SQA 


La garantía de calidad del softwarecomprende una gran 
variedad de tareas, asociadas con dos constitutivosdife- 
rentes —los ingenieros de software que realizan traba- 
jo técnico y un grupo de SQA que tiene la responsabilidad 
de la Planificación de garantía de calidad, supervisión, 
mantenimiento de registros, análisis e informes —. 

Los ingenieros de software afrontan la calidad (y rea- 
lizan garantía de calidad) aplicando métodos técnicos 
sólidos y medidas, realizando revisiones técnicas for- 
males y llevando a cabo pruebas de software bien pla- 
nificadas. Solamente las revisiones son tratadas en este 
capítulo. Los temas de tecnología se estudianen las Par- 
tes Tercera a Quinta de este libro. 

Las reglas del grupo de SQA tratan de ayudar al equi- 
po de ingeniería del software en la consecución de un pro- 
ducto final de alta calidad. El Instituto de Ingeniería del 
Software [PAU93] recomienda un conjunto de activida- 
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des de SQA que se enfrentan con la planificación de garan- 
tía de calidad, supervisión, mantenimiento de registros, 
análisis e informes. Éstas son las actividades que realizan 
(ofacilitan) un grupo independiente de SQA: 

Establecimiento de unplan de SOA para un proyec- 
to. El plan se desarrolla durante la planificación del pro- 
yecto y es revisado por todas las partes interesadas. Las 
actividades de garantía de calidad realizadas por el equi- 
po de ingeniería del software y el grupo SQA son gober- 
nadas por el plan. El plan identifica: 


» evaluaciones a realizar, 
* auditorías y revisiones a realizar, 
» estándares que se pueden aplicar al proyecto, 


* procedimientos para información y seguimiento de 
errores, 


+ documentos producidos por el grupo SQA, 


« realimentación de información proporcionada al 
equipo de proyecto del software. 


Participación en el desarrollo de la descripción del 
proceso de software del proyecto. El equipo de ingenie- 
ría del software selecciona un proceso para el trabajo 
que se va arealizar. El grupo de SQA revisa la descrip- 
ción del proceso para ajustarse a la política de la empre- 
sa, los estándares internos del software, los estándares 
impuestos externamente (por ejemplo: ISO 9001), y a 
otras partes del plan de proyecto del software. 

Revisión de las actividades de ingeniería del soft- 
ware para verificar su ajuste al proceso de software 
definido. El grupo de SQA identifica, documenta y sigue 
la pista de las desviaciones desde el proceso y verifica 
que se han hecho las correcciones. 

Auditoría de losproductos de software designados 
para verificar el ajuste con los definidos comoparte del 
proceso del software. El grupo de SQA revisa los pro- 
ductos seleccionados; identifica, documenta y sigue la 
pista de las desviaciones; verifica que se han hecho las 
correcciones, e informa periódicamente de los resulta- 
dos de su trabajo al gestor del proyecto. 

Asegurar que las desviaciones del trabajo y los pro- 
ductos del software se documentan y se manejan de 
acuerdo con un procedimiento establecido. Las des- 
viaciones se pueden encontrar en el plan del proyecto, 
en la descripción del proceso, en los estándares aplica- 
bles o en los productos técnicos. 

Registrar lo que no se ajuste a los requisitos e infor- 
mar a sus superiores. Los elementos que no se ajustan 
a los requisitos están bajo seguimiento hasta que se 
resuelven. 


¿Cuál es el papel 
de un grupo de $QA? 


Además de estas actividades, el grupo de SQA coor- 
dina el control y la gestión de cambios (Capítulo 9) y ayu- 
da arecopilar y a analizar las métricas del software. 
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Las revisiones del software son un «filtro» para el pro- 
ceso de ingeniería del software. Esto es, las revisiones 
Se aplican en varios momentos del desarrollo del soft- 
war y sirven para detectar errores y defectos que pue- 
dan así sereliminados. Las revisiones del software sirven 
para «purificar» las actividades de ingeniería del soft- 
ware que suceden como resultado del análisis, el diseño 
y la codificación. Freedman y Weinberg [FRE90] argu- 
mentan de la siguiente forma la necesidad de revisiones: 


El trabajo técnico necesita serrevisado por la misma razón 
que los lápices necesitan gomas: errar es humano. La segunda 
razón por la que necesitamos revisiones técnicas es que, aun- 
quela gente es buena descubriendo algunos de sus propios erro- 
res, algunas clases de errores se le pasan por alto más fácilmente 
al que los origina que a otras personas. El proceso de revisión 
es, por tanto, la respuesta a la plegaria de Robert Bums: 


¡Qué gran regalo seríapoder vemos comonos ven los demás! 


Una revisión —cualquier revisión — es una forma de apro- 
vechar la diversidad de un grupo de personas para: 


1. señalar la necesidad de mejoras en el producto de una 
sola persona o un equipo; 

2. confirmarlas partes de un producto en las que no es nece- 
sariao no es deseable una mejora; y 

3. conseguir un trabajo técnico de una calidad más unifor- 
me, o al menos más predecible, que la que puede ser con- 
seguida sin revisiones, con el £n de hacer más manejable 
el trabajo técnico. 


Conse) 


Aligual que los filtros de agua, las RTF's tienden o 
retardar el «lujo» de las actividades de ingeniería del 
software. Muy pocos y el flujo es «sucio». Muchos y el 
flujo se reducirá o un goteo. Utilice métricos poro 
determinar qué revisiones son efectivas y cuáles no. 
Saque los que no sean efectivos fuero del flujo. 


Existen muchos tipos diferentes de revisiones que se 
pueden llevar adelante como parte de la ingeniería del 
software. Cada una tiene su lugar. Una reunión infor- 
mal alrededor de la máquina de café es una forma de 
revisión, si se discuten problemas técnicos. Una pre- 
sentación formal de un diseño de software a una audien- 
cia de clientes, ejecutivos y personal técnico es una 
forma de revisión. Sin embargo, en este libro nos cen- 
traremos en la revisión técnicaformal (RTF)—a veces 
denominada inspección —. Una revisión técnica formal 
esel filtro más efectivo desde el punto de vista de garan- 
tia de calidad. Llevada a cabo por ingenieros del soft- 
ware (y otros), la RTF es para ellos un medio efectivo 
para mejorar la calidad del software. 


8.4.1. Impacto de los defectos del software sobre 
el coste 


El /EEE Standard Dictionary of Electrical and Elec- 
tronics Terms (IEEE Standard 100-1992) define un 


defecto como una «anomalía del producto». La defini- 
ción de «fallo» en el contexto del hardware se puede 
encontrar en IEEE Standard 610. 12-1990: 


(a) Un defecto en un dispositivo de hardware o componen- 
te: por ejemplo, un corto circuito o un cable roto. 


(b) Un paso incorrecto, proceso o definición de datos en 
un programa de computadora. Nota: Esta definición 
se usa principalmente por la disciplina de tolerancia 
de fallos. En su uso normal, los términos «error» y 
«fallo» se utilizan para expresar este significado. Con- 
sulte también: fallo sensible al dato; fallo sensible al 
programa; fallos equivalentes; enmascaramiento de 
fallos; fallo intermitente. 


Dentro del contexto del proceso del software, los tér- 
minos defecto y fallo son sinónimos. Ambos implican 
un problema de calidad que es descubierto después de 
entregar el software a los usuarios finales (o a otra acti- 
vidad del proceso del software). En los primeros capí- 
tulos, se utilizó el término error para representar un 
problema de calidad que es descubierto por los inge- 
nieros del software (u otros) antes de entregar el soft- 
ware al usuario final (o a otra actividad del proceso del 
software). 


Paso de desarrollo 
Defectos 


Detección 


Errores 
de pasos 
anterores Errores 
pasados al 


siguiente paso 


FIGURA 8.2. Modelo de amplificación de defectos. 


El objetivo primario de las revisiones técnicas for- 
males es encontrar errores durante el proceso, de forma 
que se conviertan en defectos después de la entrega del 
software. El beneficio obvio de estas revisiones técni- 
cas formales es el descubrimiento de errores al princi- 
pio para que no se propaguen al paso siguiente del 
proceso del software. 


ey VE 


El objetivo principal de una RTFes encontar errores 
antes de pasar a otra acividad de ingenieía 
del software o de entregar al clente. 


Una serie de estudios (TRW, Nippon Electric y Mitre 
Corp., entre otros) indican que las actividades del dise- 
ño introducen entre el 50 al 65 por ciento de todos los 
errores (y en último lugar, todos los defectos) durante 
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el proceso del software. Sin embargo, se ha demostra- 
do que las revisiones técnicas formales son efectivas en 
un 75 por 100 a la hora de detectar errores [JON86]. 
Con la detección y la eliminación de un gran porcenta- 
je de errores, el proceso de revisión reduce substan- 
cialmente el coste de los pasos siguientes en las fases 
de desarrollo y de mantenimiento. 

Para ilustrar el impacto sobre el coste de la detec- 
ción anticipada de errores, consideremos una serie de 
costesrelativos que se basan en datos de coste realmente 
recogidos en grandes proyectos de software [IBM81]?. 
Supongamos que un error descubierto durante el dise- 
ño cuesta corregirlo 1,0 unidad monetaria. De acuerdo 
con este coste, el mismo error descubierto justo antes 
de que comienza la prueba costará 6,5 unidades; duran- 
te la prueba 15unidades; y después de la entrega, entre 
60 y 100 unidades. 


8.4.2. Amplificación y eliminación de defectos 


Se puede usar un modelo de amplificación de defectos 
[IBM81] para ilustrarla generación y detección de erro- 
res durante los pasos de diseño preliminar, diseño deta- 
llado y codificación del proceso de ingeniería del 
software. En la Figura 8.2 se ilustra esquemáticamente 
el modelo. Cada cuadro representa un paso en el desa- 
rrollo del software. Durante cada paso se pueden gene- 
rar errores que se pasan inadvertidos. La revisión puede 
fallar en descubrir nuevos errores y errores de pasos 
anteriores, produciendo un mayor número de errores 
que pasan inadvertidos. En algunos casos, los errores 
que pasan inadvertidos desde pasos anteriores se ampli- 
fican (factor de amplificación, x) con el trabajo actual. 
Las subdivisiones de los cuadros representan cada una 
de estas características y el porcentaje de eficienciapara 
la detección de errores, una función de la profundidad 
de la revisión. 

La Figura 8.3 ilustra un ejemplo hipotético de la ampli- 
ficación de defectos en un proceso de desarrollo de soft- 
ware en el que no se llevan a cabo revisiones. Como 
muestra la figura, se asume que cada paso descubre y 


corrigeel 50 por 100 de los errores que le llegan, sin intro- 
ducir ningún error nuevo (una suposición muy optimis- 
ta). Antes de que comience la prueba, se han amplificado 
diez errores del diseño preliminar a 94 errores. Al termi- 
nar quedan 12 errores latentes. La Figura 8.4 considera 
las mismas condiciones, pero llevando a cabo revisiones 
del diseño y de la codificación dentro de cada paso del 
desarrollo. En este caso los 10errores del diseño preli- 
minar se amplificana 24 antes del comienzo de la prue- 
ba. Sólo quedan 3 errores latentes. Recordandolos costes 
relativos asociados con el descubrimientoy la corrección 
de errores, se puede establecer el coste total (con y sin 
revisiones para nuestro ejemplo hipotético). El número 
de errores encontrado durante cada paso mostrado en las 
figuras 8.3 y 8.4 se multiplica por el coste de eliminarun 
error (1.5 unidades de coste del diseño, 6.5 unidades de 
coste antes de las pruebas, 15 unidades de coste durante 
las pruebas, y 67 unidades de coste después de la entre- 
ga. Utilizando estos datos, se puede ver que el coste total 
para el desarrollo y el mantenimientocuando se realizan 
revisiones es de 783 unidades. Cuando no hay revisio- 
nes, el coste totales de 2.177 unidades —cas1 tres veces 
más caro—. 


medodes, como dicen los médicos, en 
o son fáciles de curar pero difíciles de 
“pero con el paso del tiempo, cuando no 
nocido y tratado al principio, se vuelven 
teconocer pero difíciles de curar. 


A 


Para llevar a cabo revisiones, el equipo de desarrollo 
debe dedicar tiempo y esfuerzo, y la organización de 
desarrollo debe gastar dinero. Sin embargo, los resulta- 
dos del ejemplo anterior no dejan duda de que hemos 
encontrado el síndrome de «pague ahora O pague, des- 
pués, mucho más». Las revisiones técnicas formales (para 
el diseño y otras actividadestécnicas) producen un bene- 
ficio en coste demostrable. Deben llevarse a cabo. 


Una revisión técnica formal (RTF) es una actividad de 
garantía de calidad del software llevada a cabo por los 
ingenieros del software (y otros). Los objetivos de la 
RTF son: (1) descubrir errores en la función, la lógi- 
ca O la implementación de cualquier representación 
del software; (2) verificar que el software bajo revi- 
sión alcanza sus requisitos; (3) garantizar que el soft- 
ware ha sido representado de acuerdo con ciertos 
estándares predefinidos; (4) conseguir un software 


3 Aunque estos datos son de hace más de 20 años, pueden ser apli- 
cados en un contexto moderno. 
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desarrollado de forma uniforme y (5) hacer que los 
proyectos sean más manejables. Además, la RTF sir- 
ve como campo de entrenamiento, permitiendo que los 
ingenieros más jóvenes puedan observar los diferen- 
tes enfoques de análisis, diseño e implementación del 
software. La RTF también sirve para promover la segu- 
ridad y la continuidad, ya que varias personas se fami- 
liarizarán con partes del software que, de otro modo, 
no hubieran visto nunca. 
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La RTF es realmente una clase de revisión que inclu- 
ye recorridos, inspecciones, revisiones cíclicas y otro 
pequeño grupo de evaluaciones técnicas del software. 
Cada RTF se lleva a cabo mediante una reunión y sólo 
tendrá éxito si es bien planificada, controlada y atendi- 
da. En las siguientes secciones se presentan directrices 
similares a las de las inspecciones [FRE90, GIL93] como 
representativas para las revisiones técnicas formales. 


Diseño preliminar 


Diseño detallado 
5 Codificación/ 


Prueba de unidad 


Para la integración 


Prueba del sistema 


Errores latentes 


FIGURA 8.3. Amplificación de defectos, sin revisiones. 


Diseño preliminar 


Diseño detallado 
Codificación! 
Prueba de unidad 


24 Prueba de integración 


Prueba de validación Para la integracion 


Errores latentes 
FIGURA 8.4. Amplificación de defectos, llevando a cabo 
revisiones. 


8.5.1, La reunión de revisión 

Independientemente del formato que se elija para la 

RTF, cualquierreunión de revisión debe acogerse a las 

siguientes restricciones: 

* deben convocarse para la revisión (normalmente) 
entre tres y cinco personas; 

* sedebe preparar por adelantado, pero sin que requiera 
más de dos horas de trabajo a cada persona; y 

« la duración de la reunión de revisión debe ser menor 
de dos horas. 


ha Cuando realizamos RTF's, 
¿cuáles son nuestros 
objetivos? 


139 


ear na mao e rec  TÍA DE CALIDAD DEL SOFTWARE 


te un evento donde 
tos y se pierden horos. 


Con las anteriores limitaciones, debe resultar obvio 
que cada RTF se centra en una parte específica (y 
pequeña) del software total. Por ejemplo, en lugar de 
intentar revisar un diseño completo, se hacen ins- 
pecciones para cada módulo (componente) o peque- 
ño grupo de módulos. Al limitar el centro de atención 
de la R'TF, la probabilidad de descubrir errores es 
mayor. 

El centro de atención de la RTF es un producto de 
trabajo (por ejemplo, una porción de una especifica- 
ción de requisitos, un diseño detallado del módulo, 
un listado del código fuente de un módulo). El indi- 
viduo que ha desarrollado el producto —el produc- 
tor — informa al jefe del proyecto de que el producto 
está terminado y que se requiere una revisión. Eljefe 
del proyecto contacta con unjefe de revisión, que eva- 
lúa la disponibilidad del producto, genera copias del 
material del producto y las distribuye a dos o tres revi- 
sores para que se preparen por adelantado. Cada revi- 
sor estará entre una y dos horas revisando el producto, 
tomando notas y también familiarizándose con el tra- 
bajo. De forma concurrente, también el jefe de revi- 
sión revisa el producto y establece una agenda para 
la reunión de revisión que, normalmente, queda con- 
vocada para el día siguiente. 


Cc VE 


la RTF se centra en una porción relativamente pequeña 
de un producto de trabajo. 


La reunión de revisión es llevada a cabo por el jefe 
de revisión, los revisores y el productor. Uno de los revi- 
sores toma el papel de registrador, o sea, de persona que 
registra (de forma escrita) todos los sucesos importan- 
tes que se produzcan durante la revisión. La RTF 
comienza con una explicación de la agenda y una bre- 
ve introducción a cargo del productor. Entonces el pro- 
ductor procede con el «recorrido de inspección» del 
producto, explicando el material, mientras que los revi- 
sores exponen sus pegas basándose en su preparación 
previa. Cuando se descubren problemas o errores váli- 
dos, el registrador los va anotando. 


9, 
¡0 
Referencia Web] * 
Puede descargarse el NASA SATC 

Formal Inspection Guideboock de 
satc.gsfc.nasa.gov /fi/fipage.html 
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Al final de la revisión, todos los participantes en la 
RTF deben decidir si (1) aceptan el producto sin poste- 
riores modificaciones; (2) rechazan el producto debido 
a los serios errores encontrados (una vez corregidos, ha 
de hacerse otra revisión) O (3 Jaceptan el producto pro- 
visionalmente (se han encontrado errores menores que 
deben ser corregidos, pero sin necesidad de otra poste- 
rior revisión). Una vez tomada la decisión, todos los 
participantes terminan firmando, indicando así que han 
participado en la revisión y que están de acuerdo con 
las conclusiones del equipo de revisión. 


8.5.2. Registro e informe de la revisión 


Durante la RTF, uno de los revisores (el registrador) 
procede a registrar todas las pegas que vayan surgien- 
do. Al final de la reunión de revisión, resume todas las 
pegas y genera una lista de sucesos de revisión. Ade- 
más, prepara un informe sumario de la revisión técnica 
formal. El informe sumario de revisión responde a tres 
preguntas: 


1. ¿Qué fue revisado? 

2. ¿Quién lo revisó? 

3. ¿Qué se descubrió y cuáles son las conclusiones? 
El informe sumario de revisión es una página sim- 

ple (con posibles suplementos). Se adjunta al registro 


histórico del proyecto y puede ser enviada al jefe del 
proyecto y a otras partes interesadas. 


Informe Sumario! y lista de Suoesos de Revisión Técnica 


La lista de sucesos de revisión sirve para dos pro- 
pósitos: (1) identificar áreas problemáticas dentro del 
producto y (2) servir como lista de comprobación de 
puntos de acción que guíe al productor para hacer las 
correcciones. Normalmente se adjunta una lista de con- 
clusiones al informe sumario. 

Es importante establecer un procedimiento de segui- 
miento que asegure que los puntos de la lista de suce- 
sos son corregidos adecuadamente. A menos que se haga 
así, es posible que las pegas surgidas «caigan en saco 
roto», Un enfoque consiste en asignar la responsabili- 
dad del seguimiento al revisor jefe 


8.5.3. Directrices para la revisión 


Se deben establecer de antemano directrices para con- 
ducir las revisiones técnicas formales, distribuyéndolas 
después entre los revisores, para ser consensuadas y, 
finalmente, seguidas. A menudo, una revisión incon- 
trolada puede ser peor que no hacer ningún tipo de revi- 
sión. A continuación se muestra un conjunto mínimo de 
directrices para las revisiones técnicas formales: 
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1 Revisar elproducto, no alproductor. Una RTF invo- 
lucra gente y egos. Conducida adecuadamente, la 
RTF debe llevar atodos los participantes a un senti- 
miento agradable de estar cumpliendo su deber. Si 
se lleva a cabo incorrectamente, la RTF' puede tomar 
el aura de inquisición. Se deben señalar los errores 
educadamente; el tono de la reunión debe ser dis- 
tendido y constructivo; no debe intentarse dificultar 
O batallar. El jefe de revisión debe moderar la reu- 
nión para garantizar que se mantiene un tono y una 
actitud adecuados y debe inmediatamente cortar cual- 
quier revisión que haya escapado al control. 


"MOE 


No señale bruscamentelos errores. Una forma de ser 
educada es hacer una pregunto que permita al productor 
descubrir su propia errar. 


. Fijar una agenda y mantenerla. Un mal de las reu- 
niones de todo tipo es la deriva. La RTF debe seguir 
un plan de trabajo concreto. El jefe de revisión es el 
que carga con la responsabilidad de mantener el plan 
de la reunión y no debe tener miedo de cortar a la 
gente cuando se empiece a divagar. 

. Limitar el debate y las impugnaciones. Cuando un 
revisor ponga de manifiesto una pega, podrá no haber 
unanimidad sobre su impacto. En lugar de perder el 
tiempo debatiendo la cuestión, debe registrarse el 
hecho y dejar que la cuestión se lleve a cabo en otro 
momento. 

. Enunciar áreas de problemas, pero no intentar resol: 
ver cualquier problema que se ponga de manifiesto. 
Una revisión no es una sesión de resolución de pro- 
blemas. A menudo, la resolución de los problemas 
puede ser encargada al productor por sí solo o con 
la ayuda de otra persona. La resolución de los pro- 
blemas debe ser pospuesta para después de la reu- 
nión de revisión. 


ed 

de los compensaciones más bonitas 

"ningún hombre puede sinceramente 
q otto sin ayudarse a SÍ mismo. 


. Tomar notas escritas. A veces es buena idea que el 
registrador tome las notas en una pizarra, de forma 
que las declaraciones O la asignación de prioridades 
pueda ser comprobada por el resto de los revisores, 
a medida que se va registrando la información. 

. Limitar el número de participantes e insistiren lapre- 
paración anticipada. Dos personas son mejores que 
una, pero catorce no son necesariamente mejores que 
cuatro. Se ha de mantener el número de participantes 
en el mínimo necesario. Además. todos los miembros 
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del equipo de revisión deben prepararse por anticipado. 
El jefe de revisión debe solicitar comentarios (que 
muestren que cada revisor ha revisado el material). 


7. Desarrollar una lista de comprobación para cada 
producto que haya de ser revisado, Una lista de com- 
probaciones ayuda al jefe de revisión a estructurar 
la reunión de RTF y ayuda a cada revisor a centrarse 
en los asuntos importantes. Se deben desarrollar lis- 
tas de comprobaciones para los documentos de aná- 
lisis, de diseño, de codificación e incluso de prueba. 


listas de comprobación de RTF 


8. Disponer recursos y una agenda para las RTF. Para 
que las revisiones sean efectivas, se deben planificar 
como una tarea del proceso de ingeniería del soft- 
ware. Además se debe trazar un plan de actuación 
para las modificaciones inevitables que aparecen 
como resultado de una RTF. 


CAPITULO 8 GARANTÍA DE CALIDAD DEL SOFTWARE 


9. Llevar a cabo un buen entrenamiento de todos los 


revisores. Por razones de efectividad, todos los par- 
ticipantes en la revisión deben recibir algún entre- 
namiento formal. El entrenamiento se debe basar en 
los aspectos relacionados con el proceso, así como 
las consideraciones de psicología humana que ata- 
ñen a la revisión. Freedman y Weinberg [FRE90] 
estiman en un mes la curva de aprendizaje para cada 
veinte personas que vayan a participar de forma efec- 
tiva en las revisiones. 


10. Repasar las revisiones anteriores. Las sesiones de 


información pueden ser beneficiosas para descubrir 
problemas en el propio proceso de revisión. El pri- 
mer producto que se haya revisado puede estable- 
cer las propias directivas de revisión. 


Como existen muchas variables (por ejemplo, núme- 


ro de participantes, tipo de productos de trabajo, tiem- 
po y duración, enfoque de revisión específico) que tienen 
impacto en una revisión satisfactoria, una organización 
de software debería determinar qué método funciona 
mejor en un contexto local. Porter y sus colegas 
[POR95] proporcionan una guía excelente para este tipo 
de experimentos. 


La garantía de calidad estadística refleja una ten- 
dencia, creciente en toda la industria, a establecer la 
calidad más cuantitativamente. Para el software, la 
garantía de calidad estadística implica los siguientes 
pasos: 


1. Se agrupa y se clasifica la información sobre los 
defectos del software. 


2. Se intenta encontrar la causa subyacente de cada 
defecto (por ejemplo, no concordancia con la espe- 
cificación, error de diseño, incumplimiento de los 
estándares, pobre comunicación con el cliente). 


ó$ ¿Qué pasos se requieren 
para desarrollar una SQA 


estadística? 


3, Mediante el principio de Pareto (el 80 por 100 de los 
defectos se pueden encontrar en el 20 por 100 de 
todas las posibles causas), se aísla el 20por 100(los 
«pocos vitales»). 


4. Una vez que se han identificado los defectos vitales, 
se actúa para corregir los problemas que han produ- 
cido los defectos. 


Este concepto relativamente sencillo representa un 
¿ paso importantehacia la creaciónde un proceso de inge- 
niería del software adaptativoen el cual se realizan cam- 
bios para mejorar aquellos elementos del proceso que 
introducen errores. 
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Para ilustrar el proceso, supongamos que una orga- 


nización de desarrollo de software recoge información 
sobre defectos durante un período de un año. Algunos 
de los defectos se descubren mientras se desarrolla el 
software. Otros se encuentran después de que el soft- 
ware se haya distribuido al usuario final. Aunque se des- 
cubren cientos de errores diferentes, todos se pueden 
encontrar en una (o más) de las siguientes causas: 


Especificación incompleta o errónea (EIE). 

Mala interpretación de la comunicación del cliente 
(MCC). 

Desviación deliberada de la especificación (DDE). 
Incumplimiento de los estándares de programación 
(EP). 

Error en la representación de los datos (ERD). 
Interfaz de módulo inconsistente (IMD. 

Error en la lógica de diseño (ELD). 

Prueba incompleta o errónea (PIBE). 
Documentación imprecisa o incompleta (DID. 


Error en la traducción del diseño al lenguaje de pro- 
gramación (TLP). 
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Interfaz hombre-máquina ambigua o inconsistente 
(1HM). 
Varios (VAR). 


Referencia En 


la Asociación China de Calidad del Software presenta 
uno de los sitios web más completos para la calidad en 
WWW.COSQ.Org 


Para aplicar la SQA estadística se construye la Tabla 
8.1. La tabla indica que EIE, MCC y ERD son las cau- 
sas vitales que contabilizan el 53 por 100 de todos los 
errores. Sin embargo, debe observarse que si sólo se 
consideraran errores serios, se seleccionarían las siguien- 
tes causas vitales: EJE, ERD, TLP y ELD. Una vez deter- 
minadas las causas vitales, la organización de desarrollo 
de software puede comenzar la acción correctiva. Por 
ejemplo, para corregir la MCC, el equipo de desarrollo 
del software podría implementar técnicas que facilita- 
ran la especificación de la aplicación (Capítulo 11)para 
mejorar la calidad de la especificación y la comunica- 
ción con el cliente. Para mejorar el ERD, el equipo de 
desarrollo del software podría adquirir herramientas 
CASE para la modelización de datos y realizar revisio- 
nes del diseño de datos más rigurosas. 

Es importante destacar que la acción correctiva se 
centra principalmente en las causas vitales. Cuando éstas 
son corregidas, nuevas candidatas saltan al principio de 
la lista. 

Se han mostrado las técnicas de garantía de calidad 
del software estadísticas para proporcionar una mejora 
sustancial en la calidad [ART97]. En algunos casos, las 
organizaciones de software han conseguido una reduc- 
ción anual del 50 por 100 de los errores después de la 
aplicación de estas técnicas. 

Junto con la recopilación de información sobre defec- 
tos, los equipos de desarrollo del software pueden cal- 
cular un indice de errores (IE) para cada etapa principal 
del proceso de ingeniería del software [1EE94]. Des- 
pués del análisis, el diseño, la codificación, la prueba y 
la entrega, se recopilan los siguientes datos: 

E, = número total de defectos descubiertos durante la eta- 
pa 1-ésima del proceso de ingeniería del software; 

S¡= número de defectos graves; 

M; =número de defectos moderados; 

T; = número de defectos leves; 

PS =tamaño del producto (LDC, sentencias de diseño, 
páginas de documentación) en la etapa i-ésima. 

W, W,,, W, =1factores de peso de errores graves, mode- 
rados, y leves, en donde los valores recomendados 
son W, = 10,W, =3,W, = 1. Los factores de peso 
de cada fase deberían agrandarse a medida que el 
desarrollo evoluciona. Esto favorece a la organi- 
zación que encuentra los errores al principio. 
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En cada etapa del proceso de ingeniería del softwa- 
re se calcula un índice defase, IF; E 
IE; =W, (S/E¡) +W,, (M¡¡E¡) + W, (T¡/E/) 


un” 1 


El indice de errores (1E) se obtiene mediante el cálcu- 
lo del defecto acumulativo de cada IF?, asignando más 
peso a los errores encontrados más tarde en el proceso de 
ingeniería del software, que a los que se encuentranen las 
primeras etapas: 


IE = Y (ix 1F,) /PS 
= (IF, +21E, +3IF, + ... ¡TF,) / PS 


Total Grave Moderado Leve 
Error No. % No. % No. % No. % 
TEE 205 22% 34 271% 68 18% 103 24% 
MCC 156 17% 12 9% 68 18% 76 171% 
DDE 48 5% 1 1% 24 6% 23 5% 
TEP 25 3% 0 0% 15 4% 10 2% 
ERD 130 14% 26 20% 68 18% 36 8% 
IMI 58 6% 9 “1% 18 5% 31 71% 
ELD 45 5% 14 11% 12 3% 19 4% 
PIE 95 10% 12 9% 35 9% 48 11% 
DI 36 4% 2 2% 20 5% 14 3% 
TLP 60 6% 15 12% 19 5% 26 6% 
THM 28 3% 3 2% 17 4% 8 2% 
VAR 56 6% 0 0% 154% 41 9% 
Totales 942 100% 128 100% 379 100% 435 100% 


TABLA 8.1. Recolección de datos para la SQA estadística 


Se puede utilizar el índice de errores junto con la 
información recogida en la Tabla 8.1, para desarrollar 
una indicación global de la mejora en la calidad del soft- 
ware. 

La aplicación de la SQA estadística y el principio de 
Pareto se pueden resumir en una sola frase: ¡ Utilizar el 
tiempo para centrarse en cosas que realmente intere- 
san, peroprimero asegurarse que se entiende qué es lo 
que realmente interesa! 

Un estudio exhaustivo de la SQA estadística se sale 
del alcance de este libro. Los lectores interesados debe- 
rían consultar [SCH987, [KAP95] y [KAN95]. 
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CAPITULO 8 GARANTIA DE CALIDAD DEL SOFTWARE 


No hay duda de que la fiabilidad de un programa de 
computadora es un elemento importante de su calidad 
general. Si un programa falla frecuente y repetidamen- 
te en su funcionamiento, no importa si el resto de los 
factores de calidad son aceptables. 


Referencia 


E-Centro de Análisis de Fiabilidad proporciona mucha 
información útil sobre la fiabilidad, mantenibilidad, 
soporte y calidad en rac.iitri.org 


La fiabilidad del software, a diferencia de otros 
factores de calidad, puede ser medida o estimada 
ffiediante datos históricos o de desarrollo. La fiabili- 
Had del software se define en términos estadísticos 
kómo «la probabilidad de operación libre de fallos de 
*n programa de computadora en un entorno determi- 
hado y durante un tiempo específico» [MUS87]. Por 
ejemplo, un programa X puede tener una fiabilidad 
estimada de 0,96 durante un intervalo de proceso de 
veho horas. En otras palabras, si se fuera a ejecutar el 
programa X 100 veces, necesitando ocho horas de 
tiempo de proceso (tiempo de ejecución), lo probable 
*sque funcione correctamente (sin fallos) 96 de cada 
1100 veces. 
*2 Siempre que se habla de fiabilidad del software, sur- 
gela pregunta fundamental: ¿Qué se entiende por el tér- 
mino fallo? En el contexto de cualquier discusión sobre 
calidad y fiabilidad del software, el fallo es cualquier 
falta de concordancia con los requisitos del software. 
Incluso en esta definición existen grados. Los fallos pue- 
den ser simplemente desconcertantes o ser catastrófi- 
os. Puede que un fallo sea corregido en segundos 
mientras que otro lleve semanas o incluso meses. Para 
complicar más las cosas, la corrección de un fallo pue- 

llevar a la introducción de otros errores que, final- 
mente, lleven a más fallos. 


dz. Medidas de fiabilidad y de disponibilidad 
Los primeros trabajos sobre fiabilidad intentaron extra- 
polar las matemáticas de la teoría de fiabilidad del hard- 
“yare (por ejemplo: [ALV64]) a la predicción de la 
fiabilidad del software. La mayoría de los modelos de 
fiabilidad relativos al hardware van más orientados a 
dos fallos debidos al desajuste que a los fallos debidos 
«defectos de diseño. En el hardware, son más proba- 
bles los fallos debidos al desgaste físico (por ejemplo: 
el efecto de la temperatura, de la corrosión y los gol- 

) que los fallos relativos al diseño. Desgraciadamente, 
E el softwarelo que ocurre es lo contrario. De hecho, 
05 los fallos del software, se producen por proble- 
nas de diseño O de implementación; el desajuste (con- 
sulte el Capítulo 1) no entra en este panorama. 
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5] 
e 


CLAVE 


Los problemas de la fiabilidad del software se deben casi 
siempre a errores en el diseño o en la implementación. 


Todavía se debate sobre la relación entre los con- 
ceptos clave de la fiabilidad del hardware y su aplica- 
bilidad al software (por ejemplo, [LIT89], [ROO90)). 
Aunque aún falta por establecer un nexo irrefutable, 
merece la pena considerar unos cuantos conceptos que 
conciernen a ambos elementos de los sistemas. 

Considerando un sistema basado en computadora, 
una sencilla medida de la fiabilidad es el tiempo medio 
entre fallos (TMEF), donde; 


TMEF =TMDF + TMDR 


Las siglas TMDF y TMDR corresponden a tiempo 
medio de fallo y tiempo medio de reparación, respecti- 
¿Por qué es TWEF 


vamente. 
3 una métrica más útil 


que errores /LDC? 


Muchos investigadores argumentan que el TMDF 
es, con mucho, una medida más Útil que los defec- 
tos/KLDC o defectos/PF. Sencillamente, el usuario 
final se enfrenta a los fallos, no al número total de erro- 
res. Como cada error de un programa no tiene la mis- 
ma tasa de fallo, la cuenta total de errores no es una 
buena indicación de la fiabilidad de un sistema. Por 
ejemplo, consideremos un programa que ha estado fun- 
cionando durante 14meses. Muchos de los errores del 
programa pueden pasar desapercibidos durante déca- 
das antes de que se detecten. El TMEF de esos erro- 
res puede ser de 50 e incluso de 100 años. Otros 
errores, aunque no se hayan descubierto aún, pueden 
tener una tasa de fallo de 186 24 meses. Incluso aun- 
que se eliminen todos los errores de la primera cate- 
goría (los que tienen un gran TMEP), el impacto sobre 
la fiabilidad del software será muy escaso. 

Además de una medida de la fiabilidad debemos 
obtener una medida de la disponibilidad. La disponibi- 
lidad del software es la probabilidad de que un progra- 
ma funcione de acuerdo con los requisitos en un 
momento dado, y se define como: 


Disponibilidad = [TMDE/(TMDF +TMDR)] x 100% 


La medida de fiabilidad TMEF es igualmente sen- 
sible al TMDF que al TMDR. La medida de disponi- 
bilidad es algo más sensible al TMDR, una medida 
indirecta de la facilidad de mantenimiento del soft- 
ware. 
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8.7.2. Seguridad del software 


Leveson [LEV86] discute el impacto del software en 
sistemas críticos de seguridad, diciendo: 


Antes de que se usara softwareen sistemascríticosde segu- 
ridad, normalmente éstos se controlaban mediante dispositi- 
vos electrónicos y mecánicos convencionales (no progra- 
mables). Las técnicas de seguridad de sistemas se diseñaban 
para hacer frente a fallos aleatorios en esos dispositivos [no 
programables]. Los errores humanos de diseño no se consi- 
deraban porque se suponía que todos los defectos producidos 
por los errores humanos se podían evitar o eliminar comple- 
tamente antes de su distribución y funcionamiento. 


soginor cualquier condición que podría 

lento de este barco. La construcción 
más allá de eso. 

»n del Titanic 


Cuando se utiliza el software como parte del siste- 
ma de control, la complejidad puede aumentar en un 
orden de magnitud o más. Los defectos sutiles de dise- 
ño, producidos por un error humano —algo que se pue- 
de descubrir y eliminar en el control convencional 
basado en el hardware — llegan a ser mucho más difí- 
ciles de descubrir cuando se utiliza el software. 

La seguridad del software es una actividad de garan- 
tía de calidad del software que se centra en la identifi- 
cación y evaluación de los riesgos potenciales que 
pueden producir un impacto negativo en el software y 
hacer que falle el sistema completo. Si se pueden iden- 
tificar pronto los riesgos en el proceso de ingeniería del 
software podrán especificarse las características del dise- 
ño del software que permitan eliminar o controlar los 
riesgos potenciales. 

Como parte de la seguridad del software, se puede 
dirigir un proceso de análisis y modelado. Inicialmente, 
se identifican los riesgos y se clasifican por su impor- 
tancia y su grado de riesgo. Por ejemplo, algunos de 
los riesgos asociados con el control basado en com- 
putadora del sistema de conducción de un automóvil 
podrían ser: 

Produce una aceleración incontrolada que no se 
puede detener. 

No responde a la presión del pedal del freno (dete- 
niéndose). 

No responde cuando se activa el contacto. 


Pierde o gana velocidad lentamente. 


Cuando se han identificado estos riesgos del siste- 
ma, se utilizan técnicas de análisis para asignar su gra- 
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Referencia 


Sé pueden encontrar documentos sobre la seguridad 
del software (y un glosario detallado) que merecen 
la peno en www.rstcorp.com/hotlist /topics- 
safety.html 


vedad y su probabilidad de ocurrencia”. Para que sea 
efectivo, se tiene que analizar el software en el contex- 
to del sistema completo. Por ejemplo, puede que un sutil 
error en la entrada del usuario (las personas son com+- 
ponentes del sistema) se magnifique por un fallo del 
software que producen los datos de control que actúan 
de forma inadecuada sobre un dispositivo mecánico. Si 
se dan un conjunto de condiciones externas del entor- 
no (y sólo si se dan), la situación inadecuada del dis- 
positivo mecánico producirá un fallo desastroso. Se 
pueden usar técnicas de análisis, como el análisis del 
árbol de fallos [VES81], la lógica de tiempo real 
[JAN86] o los modelos de redes de Petri [LEV87], para 
predecir la cadena de sucesos que pueden producir los 
riesgos y la probabilidad de que se dé cada uno de los 
sucesos que componen la cadena. 

Una vez que se han identificado y analizado los ries- 
gos, se pueden especificar los requisitos relacionados 
con la seguridad para el software. Esto es, la especifi- 
cación puede contener una lista de eventos no desea- 
bles y las respuestas del sistemaa estos eventos. El papel 
del software en la gestión de eventos no deseados es 


entonces apropiado. 
¿Cuál es la diferencia 


$ entre fiabilidad del software 
y seguridad del software? 


Aunque la fiabilidad y la seguridad del softwareestán 
bastante relacionadas, es importante entender la sutil 
diferencia que existe entre ellas. La fiabilidad del soft- 
ware utiliza el análisis estadístico para determinarla 
probabilidad de que pueda ocurrir un fallo del softwa- 
re. Sin embargo, la ocurrencia de un fallo no lleva nece- 
sariamente a un riesgo O a un accidente. La seguridad 
del software examina los modos según los cuales los 
fallos producen condiciones que pueden llevar a acci- 
dentes. Es decir, los fallos no se consideran en vacío, 
sino que se evalúan en el contexto de un completosis- 
tema basado en computadora. 

Un estudio completo sobre seguridad del software y 
análisis del riesgo va más allá del ámbitode este libro. RBxia 
aquellos lectoresque estén más interesados, deberían car 
sultar el libro de Leveson [LEV95] sobre este tema. 


4 Este método es anólogo al método de análisis de riesgos descrito 
para la gestión del proyecto de software en el capítulo 6. la princl* 
pal diferencia es el énfasis en aspectos de tecnología frente a temas 
relacionados con el proyecto. 
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..-.A4 DE CALIDAD DEL SOFTWARE 


Si William Shakespeare hubiera escrito sobre las con- 
diciones del ingeniero de software moderno, podría per- 
fectamente haber escrito: «Errar es humano, encontrar 
el error rápida y correctamente es divino.» En los años 
sesenta, un ingeniero industrial japonés, Shigeo Shin- 
go[SHI86], que trabajaba en Toyota, desarrolló una téc- 
nica de garantía de calidad que conducía a la prevención 
y/o a la temprana corrección de errores en el proceso de 
fabricación. Denominado poku-yoke (prueba de erro- 
*res),el concepto de Shingo hacía uso de dispositivos 
poku-yoke — mecanismosque conducen (1) a la pre- 
vención de un problema de calidad potencial antes de 
que éste ocurra, o (2) a la rápida detección de proble- 
mas de calidad si se han introducido ya— Nosotros 
encontramos dispositivos poka-yoke en nuestra vida 
cotidiana (incluso si nosotros no tenemos conciencia de 
este concepto). Por ejemplo, el interruptor de arranque 
de un coche no trabaja si está metida una marcha en la 


transmisión automática (un dispositivo de prevención); 


un pitido de aviso del coche sonará si los cinturones de 
seguridad no están bien sujetos (un dispositivo de detec- 
ción defallos). 

Un dispositivo de poku-yoke presenta un conjunto 
de características comunes: 


+ Es simple y barato —si un dispositivo es demasiado 
complicado y caro, no será efectivo en cuanto a 
costo= 


Es parte del proceso - esto es, el dispositivo poka- 
yoke está integrado en una actividad de ingeniería —; 


» Está localizado cerca de la tarea del proceso donde 
están ocurriendolos errores —por consiguiente pro- 
porciona una realimentación rápida en cuanto a la 
corrección de errores se refiere —. 


Referencia 


Se puede obtener una colección completa de recursos 
de poko-yoke en 

www.campbell.berry.edu /faculty /igrout/ 
pokayoke.shtml 


Aunque el poka-yoke fue originariamente desarro- 
liado para su uso en «control de calidad cero» [SHI86] 
pera el hardware fabricado, puede ser adaptado para su 
Us en ingeniería del software. Para ilustrar esto, con- 
sideremos el problema siguiente [ROB97]: 


Una compañía de productos de software vende el software 
de aplicaciónen el mercado internacional. Los menús desple- 
gables y todos los códigos asociados proporcionados con cada 
aplicación deben reflejar el lenguaje que se emplea en el lugar 
donde se usa. Por ejemplo, el elemento del menú del lenguaje 
inglés para «Close», tiene el mnemónico«C>» asociadocon ello. 
Cuando la aplicaciónse vende en un país de habla francesa, el 
mismo elemento del menú es «Fermer» con el mnemónico «PB». 
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Para llevara cabo la entrada adecuadadel menú para cada apli- 
cación, un «localizador» (una persona que habla en el idioma 
local y con la terminología de ese lugar) traduce los menús de 
acuerda con el idioma en uso. El problema es asegurar que (1) 
cada entrada de menú (pueden existir cientos de ellas) se ade- 
cue a los estándares apropiados y que no existan conflictos, 
independientemente del lenguaje que se está utilizando. 


El uso del poka-yoke para la prueba de diversos 
menús de aplicación desarrollados en diferentes len- 
guajes, tal y como se ha descrito anteriormente, se dis- 
cute en un artículo de Harry Robinson [ROB97]: 

Nosotros primero decidimos dividir el problema de prue- 
bas de menús en partes que puedan ser resueltas más fácil- 
mente. Nuestro primer avance para la resolución del problema 
fue el comprenderqueexistíandos aspectos separadospara los 
catálogos de mensaje. Había por una parte el aspecto de con- 
tenidos: las traducciones de texto muy simples tales como cam- 
biar meramente «Close» por la palabra «Fermer». Puesto que 
el equipo que realizaba las comprobacionesno hablaba de for- 
ma fluida el lenguaje en el que se pretendía trabajar, teníamos 
que dejar estos aspectos a traductores expertos del lenguaje. 

El segundo aspecto de los catálogos del mensaje era 
la estructura, las reglas sintácticas que debía obedecer 
un catálogo de objetivos adecuadamente construido. A 
diferencia del contenido, en este caso sí que era posible 
para el equipo de comprobación el verificar los aspec- 
tos estructurales de los catálogos. 

Como un ejemplo de lo que significa estructura, con- 
sideremos las etiquetas y los mnemónicos de un menú 
de aplicación. Un menú está constituido por etiquetas 
y sus mnemónicos (abreviaturas)asociados. Cada menú, 
independientemente de su contenido o su localización, 
debe obedecer las siguientes reglas listadas en la Guía 
de Estilo Motif 


Cada nemotécnico debe estar contenido en su eti- 
queta asociada; 

Cada nemotécnico debe ser único dentro del menú; 
Cada nemotécnico debe ser un carácter Único; 
Cada nemotécnico debe estar en ASCII. 


Estas reglas son invariantes a través de las localiza- 
ciones, y pueden ser utilizadas para verificar que un menú 
está correctamente construidoen la localización objetivo. 

Existen varias posibilidades para realizar la prueba 
de errores de los mnemónicos del menú: 

Dispositivo de prevención. Nosotros podemos escri- 
bir un programa para generar los mnemónicos automá- 
ticamente, dada una lista de etiquetas en cada menú. 
Este enfoque evitaría errores, pero el problema es que 
escoger un mnemónico adecuado es difícil, y el esfuer- 
zo requerido para escribir el programa no estaría justi- 
ficado con el beneficio obtenido. 

Dispositivo de prevención. Podríamos escribir un 
programa que prevendría al localizador de elegir unos 
mnemónicos que no satisfagan el criterio. Este enfoque 
también evitaría errores, pero el beneficio obtenido sería 
mínimo: los mnemónicos incorrectos son lo suficiente- 
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mente fáciles de detectar y corregir después de que apa- 
rezcan. 

Dispositivo de detección. Nosotros podríamos pro- 
porcionar un programa para verificar que las etiquetas 
del menú escogidas y los mnemónicos satisfacen los 
criterios anteriores. Nuestros localizadores podrían eje- 
cutar los programas sobre los catálogos de mensaje tra- 
ducidos antes de enviarnos a nosotros dichos catálogos. 
Este enfoque proporcionaría una realimentación rápida 
sobre los errores y será, probablemente, un paso a dar 
en el futuro. 

Dispositivode detección. Nosotros podríamos escri- 
bir un programa que verificase las etiquetas y mnemóni- 
cos del menú, y ejecutara el programa sobre catálogos de 
mensajes después de que nos los hayan devuelto los loca- 
lizadores. Este enfoque es el camino que actualmente 
estamos tomando. No es tan eficientecomo alguno de los 
riétodos anteriormente mencionados y puede requerir 
que se establezca una comunicación fluida hacia delan- 
te y hacia atrás con los localizadores, pero los errores 
detectados son incluso fáciles de corregir en este punto. 

Varios textos pequeños de poka-yoke se utilizaron 
como dispositivos poka-yoke para validar los aspectos 


estructurales de los menús .Un pequeño «script» poka- 
yoke leería la tabla, recuperaría los mnemónicos y eti- 
quetas a partir del catálogo de mensajes, y compararía 
posteriormente las cadenas recuperadas con el criterio 
establecido descrito anteriormente. 

Los «scripts» poka-yoke eran pequeños (aproximada- 
mente 100 líneas), fáciles de escribir (algunosde los escri- 
tos estaban en cuanto al tiempo por debajo de una hora) 
y fáciles de ejecutar. Nosotros ejecutábamos nuestros 
«scripts» poka-yoke sobre 16 aplicacionesen la ubicación 
en inglés por defecto y en 11 ubicaciones extranjeras. Cada 
ubicación contenía 100 menús para un total de 1.200 
menús. Los dispositivos poka-yoke encontraron 311 erro- 
res en menús y mnemónicos. Pocos de los problemas que 
nosotros descubrimos eran como muy llamativos, pero en 
total habrían supuesto una gran preocupación en la prue- 
ba y ejecución de nuestras aplicaciones localizadas. 

El ejemplo descrito antes representa un dispositivo 
poka-yoke que ha sido integrado en la actividad de prue- 
bas de ingeniería del software. La técnica poka-yoke 
puede aplicarse a los niveles de diseño, codificacióny 
pruebas y proporciona un filtro efectivo de garantía de 
calidad. 


Esta sección contiene varios objetivos, siendo el prin- 

cipal describir el cada vez más importante estándar inter- 

nacional ISO 9001. El estándar, que ha sido adoptado 
por más de 130países para su uso, se está convirtiendo 
en el medio principal con el que los clientes pueden juz- 
gar la competencia de un desarrollador de software. Uno 
de los problemas con el estándar ISO 9001 está en que 
no es específico de la industria: está expresado en tér- 
minos generales, y puede ser interpretado por los desa- 
rrolladores de diversos productos como cojinetes de 
bolas (rodamientos), secadores de pelo, automóviles, 
equipamientos deportivos y televisiones, así como por 
desarrolladores de software. Se han realizado muchos 
documentos que relacionan el estándar con la industria 
del software, pero no entran en una gran cantidad de 
detalles. El objetivo de esta sección es describir lo que 
significael ISO 9001 en términos de elementos de cali- 
dad y técnicas de desarrollo. 

Para la industria del software los estándares rele- 
vantes son: 

. 1$0 9001. Quality Systems- Modelfor Quality Assu- 
rance in Design, Development, Production, [nsta- 
llation and Servicing. Este es un estándar que 
describe el sistema de,calidad utilizado para mante- 
ner el desarrollo de un producto que implique diseño. 

+. 150 9000-3. Guidelinesfor Application of15O 9001 
to the Development, Supply and Maintainance of 
Software. Este es un documento específico que 
interpreta el ISO 9001 para el desarrollador de soft- 
ware. 


. 150 9004-2. Quality Management and Quality Sys- 
tem Elements -—Part 2— Este documento propor- 
ciona las directrices para el servicio de facilidades 
del software como soporte de usuarios. 


Los requisitos se agrupan bajo 20 títulos: 


Responsabilidad de la gestión. 

Inspección, medición y equipo de pruebas. 
Sistema de calidad. 

Inspección y estado de pruebas. 

Revisión de contrato. 

Acción correctiva. 

Control de diseño. 

Control de producto no aceptado. 

Control de documento. 

Tratamiento, almacenamiento, empaquetamiento y 
entrega. 

Compras. 

Producto proporcionado al comprador. 
Registros de calidad. 

Identificación y posibilidad de seguimientodel producto, 
Auditorías internas de calidad. 

Formación 

Control del proceso 

Servicios. 

Inspección y estado de prueba. 

Técnicas estadísticas. 


Merece la pena ver un pequeño extracto de la ISO 
9001. Este le dará al lector una idea del nivel con el que 
la ISO 9001 trata la garantía de calidad y el proceso de 
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desarrollo. El extracto elegido proviene de la sección 


1.11: 
4.11.El equipo de Inspección, medición y pruebas. 


El suministradordebe controlar, calibrar y mantenerla ins- 
pección, medir y probar el equipo, ya sea el dueño el suminis- 
trador, prestado o proporcionado por el comprador, para 
demostrar la conformidad del producto con los requisitosespe- 
cificados. El equipo debe utilizarse de un modo que asegure 
que se conoce la incertidumbre de la medición y que es con- 
sistente con la capacidad de medición requerida. 


Lo primero a destacar es su generalidad; se puede 
aplicar al desarrollador de cualquier producto. Lo 
segundo a considerar es la dificultad en la interpreta- 
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ción del párrafo —es pretendido obviamente por los 
procesos estándar de ingeniería donde equipos tales 
como indicadores de calibración y potenciómetros son 
habituales —. 

Una interpretación del párrafo anterior es que el dis- 
tribuidor debe asegurar que cualquiera de las herramien- 
tas de software utilizadas para las pruebas tiene, por lo 
menos, la misma calidad que el software a desarrollar, y 
que cualquierprueba del equipo produce valores de medi- 
ción, por ejemplo, los monitores del rendimiento, tienen 
una precisión aceptable cuando se compara con la preci- 
sión especificadapara el rendimiento en la especificación 
de los requisitos. 


Elplan de SQA proporciona un mapa para institucio- 
nalizar la garantía de calidad del software.El plan, desa- 
rrollado por un grupo de SQA, sirve como plantilla para 
actividades de SQA instituidas para cada proyecto de 
software. 


El Plan GCS 


El IEEE [[EEE94] ha recomendado un estándar para 
los planes de SQA. Las secciones iniciales describen el 
propósito y el alcance del documento e indican aque- 
llas actividades del proceso del software cubiertas por 
la garantía de calidad. Se listan todos los documentos 
señalados en el plan de SOA y se destacan todos los 
estándares aplicables. La sección de Gestión del plan 
describe la situación de la SQA dentro de la estructura 
organizativa; las tareas y las actividades de SQA y su 
emplazamiento a lo largo del proceso del software; así 
como los papeles y responsabilidades organizativas rela- 
tivas a la calidad del producto. 


La sección de Documentación describe (por referen- 
cia) cada uno de los productos de trabajo producidos como 
parte del proceso de software. Entre estos se incluyen: 


+ documentos del proyecto (por ejemplo: plan del pro- 
yecto), 
+ modelos (por ejemplo: DERSs, jerarquías de clases), 


+ documentos técnicos (por ejemplo: especificaciones, 
planes de prueba), 


+ documentos de usuario (por ejemplo: archivos de 
ayuda). 


Además, esta sección define el conjunto mínimo de 
productos de trabajo que se pueden aceptar para lograr 
alta calidad. 


Los estándares, prácticas y convenciones muestran 
todos los estándares/prácticas que se aplican durante el 
proceso de software (por ejemplo: estándares de docu- 
mentos, estándares de codificación y directrices de revi- 
sión). Además, se listan todos los proyectos, procesos y 
(en algunos casos) métricas de producto que se van areco- 
ger como parte del trabajo de ingeniería del software. 


La sección Revisiones y Auditorías del plan identi- 
fica las revisiones y auditorías que se van a llevar a cabo 
por el equipo de ingeniería del software, el grupo de 
SQA y el cliente. Proporciona una visión general del 
enfoque de cada revisión y auditoría. 


La sección Prueba hace referencia al Plan y Procedi- 
miento de Pruebas del Software (Capítulo 18). También 
define requisitos de mantenimiento de registros de prue- 
bas. La Información sobre problemas y acción correcti- 
va define procedimientos para informar, hacer segui- 
miento y resolver errores y defectos, e identifica las res- 
ponsabilidades organizativas para estas actividades. 


El resto del plan de SOA identifica las herramientas 
y métodos que soportan actividades y tareas de SQA; 
hace referencia a los procedimientos de gestión de con- 
figuración del software para controlar el cambio; defi- 
ne un enfoque de gestión de contratos; establece métodos 
para reunir, salvaguardar y mantener todos los registros; 
identifica la formación que se requiere para cumplir las 
necesidades del plan y define métodos para identificar, 
evaluar, supervisar y controlar riesgos. 
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La garantía de calidad del software es una «actividad 
de protección» que se aplica a cada paso del proceso 
del software. La SQA comprende procedimientos para 
la aplicación efectiva de métodos y herramientas, revi- 
siones técnicas formales, técnicas y estrategias de prue- 
ba, dispositivos poku-yoke, procedimientos de control 
de cambios, procedimientos de garantía de ajuste a los 
estándares y mecanismos de medida e información. 

La SQA es complicadapor la compleja naturaleza de 
la calidad del software —un atributo de los programas 
de computadora que se define como «concordanciacon 
los requisitos definidos explícita e implícitamente» —. 
Cuando se considera de forma más general, la calidad del 
software engloba muchos factores de proceso y de pro- 
ducto diferentes con sus métricas asociadas. 

Las revisiones del software son una de las activida- 
des más importantes de la SQA. Las revisiones sirven 
como filtros durante todas las actividades de ingeniería 
del software, eliminando defectos mientras que no son 
relativamente costosos de encontrar y corregir. La revi- 
sión técnica formal es una revisión específicaque se ha 
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mostrado extremadamenteefectiva en el descubrimiento 
de errores. 

Para llevar a cabo adecuadamente una garantía de 
calidad del software, se deben recopilar, evaluar y dis- 
tribuir todos los datos relacionados con el proceso de 
ingeniería del software. La SQA estadística ayuda a 
mejorar la calidad del producto y la del proceso de soft- 
ware. Los modelos de fiabilidad del software amplían 
las medidas, permitiendo extrapolar los datos recogidos 
sobre los defectos, a predicciones de tasas de fallo y de 
fiabilidad. 

Resumiendo, recordemos las palabras de Dunn y Ull- 
man [DUN32]: «La garantía de calidad del softwarees 
la guía de los preceptos de gestión y de las disciplinas 
de diseño de la garantía de calidad para el espacio tec- 
nológico y la aplicación de la ingeniería del software.) 
La capacidad para garantizar la calidad es la medida de 
madurez de la disciplina de ingeniería. Cuando se sigue 
de forma adecuada esa guía anteriormente menciona- 
da, lo que se obtiene es la madurez de la ingeniería del 
software. 
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8.1. Al principio del capítulo se señaló que «el control de varia- 
ción está en el centro del control de calidad». Como todos los 
programas que se crean son diferentes unos de otros, ¿cuáles 
son las variaciones que se buscan y cómo se controlan? 


8.2. ¿Es posible evaluar la calidad del software si el clien- 
te no se pone de acuerdo sobre lo que se supone que ha de 
hacer? 


8.3. La calidad y la fiabilidad son conceptos relacionados, 
pero son fundamentalmente diferentes en varias formas. Dis- 
cútalas. 

8.4. ¡Puede un programa ser correcto y aún así no ser fiable? 
Explique por qué. 

8.5. ¿Puede un programa ser correcto y aun asíno exhibir una 
buena calidad? Explique por qué. 


8.6. ¿Por qué a menudo existen fricciones entre un grupo de 
ingeniería del software y un grupo independiente de garantía 
de calidad del software? ¿Es esto provechoso? 


8.7. Si se le da la responsabilidad de mejorar la calidad del 
software en su organización. ¿Qué es lo primero que haría? 
¿Qué sería lo siguiente? 


8.8. Además de los errores, ¿hay otras características claras 
del software que impliquen calidad? ¿Cuáles son y cómo se 
pueden medir directamente? 


8.9. Una revisión técnica formal sólo es efectiva si todo el 
mundo se la prepara por adelantado. ¿Cómo descubriría que 
uno de los participantes no se la ha preparado? ¿Qué haría si 
fuera el jefe de revisión? 
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8.10. Algunas personas piensan que una RTF debe evaluar el 
estilo de programación al igual que la corrección. ¿Es una bue- 
na idea? ¿Por qué? 


8.11. Revise la Tabla 8.1 y seleccione las cuatro causas vita- 
les de errores serios y moderados. Sugiera acciones correc- 
toras basándose en la información presentada en otros 
capítulos. 


8.12. Una organización utiliza un proceso de ingeniería del 
software de cinco pasos en el cual los errores se encuentran 
de acuerdo a la siguiente distribución de porcentajes: 


Paso Porcentaje de errores encontrados 
1 20% 
2 15% 
3 15% 
4 40% 
5 10% 


Mediante la información de la Tabla 8.1 y la distribución de 
porcentajes anterior, calcule el índice de defectos global para 
dicha organización. Suponga que PS = 100.000. 


8.13. Investigue en los libros sobre fiabilidad del software y 
escriba un artículo que explique un modelo de fiabilidad del 
software. Asegúrese de incluir un ejemplo. 


8.14.El concepto de TMEF del software sigue abierto a deba- 
te. ¿Puede pensar en algunas razones para ello? 
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8.15. Considere dos sistemas de seguridad crítica que estén 
controlados por una computadora. Liste al menos tres peligros 
para cada uno de ellos que se puedan relacionar directamen- 
te con los fallos del software. 


8.16. Utilizando recursos web y de impresión, desarrolle un 
tutorial de 20 minutos sobrepoka-yoke y expóngaseloa su cla- 
se. 


Ss Y 


Los libros de Moriguchi (Software Excellence: A Total Qua- 
lity Management Guide, Productivity Press, 1997), Horch 
(Practical Guide to Software Quality Management, Artech 
Publishing, 1996)son unas excelentes presentaciones a nivel 
de gestión sobre los beneficios de los programas formales de 
garantía de calidad para el software de computadora. Los 
libros de Deming [DEM86] y Crosby [CRO79], aunque no 
se centran en el software, ambos libros son de lectura obli- 
gada para los gestores seniorcon responsabilidadesen el desa- 
rrollo de software. Gluckman y Roome (Everyday Heroes of 
the Quulity Movement, Dorset House, 1993) humaniza los 
aspectos de calidad contando la historia de los participantes 
en el proceso de calidad. Kan (Metrics and Models in Soft- 
ware Quality Engineering, Addison-Wesley, 1995) presenta 
una visión cuantitativade la calidad del software. Manmns (Soft- 
ware Quality Assurance, Macmillan, 1996) es una excelente 
introducción a la garantía de calidad del software. 

Tingley (Compering 150 9000, Malcom Baldridge, and 
the SET CMMfor Software, Prentice-Hall, 1996) proporciona 
una guía útil para las organizacionesque se esfuerzan en mejo- 
rar sus procesos de gestión de calidad. Oskarsson (An ISO 
9000 Approach to Building Quality Software, Prentice-Hall, 
1995) estudia cómo se aplica el estándar ISO al software. 

Durante los últimos años se han escrito docenas de libros 
sobre aspectos de garantía de calidad. La lista siguiente es 
una pequeña muestra de fuentes útiles: 

Clapp, J. A., etal., Software Quality Control, Error Analy- 
sis and Testing, Noyes Data Corp.. Park Ridge, NJ,1995, 

Dumn, R. H., yR,S. Ullman, TOM for Computer Softwa- 
re, McGrawHill, 1994. 

Fenton, N., R. Whitty y Y. lizuka, Software Quality Assu- 
rance and Measurement: Worldwide Industrial Applications, 
Chapman é Hall, 1994, 

Ferdinand, A. E., Systems, Software, and Quality Enginee- 
ring, Van Nostrand Reinhold, 1993. 

Ginac, F, P., Customer Oriented Software Quality Assu- 
rance, Prentice-Hall, 1998. 

Ince, D., /SO 9001 and Software Quality Assurance, 
McGraw-Hill, 1994. 

Ince, D., An Introduction to Software Quality Assurance 
and Implementation, McGraw-Hill, 1994. 

Jarvis, A., y Y. Crandall, Inroads to Software Quality: 
«How To» Guide and Toolkit, Prentice-Hall, 1997. 
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8.17. Sugiera unos cuantos dispositivos poka-yoke que pue: 
dan ser usados para detectar y/o prevenir errores que son 
encontrados habitualmente antes de «enviar» un mensaje 
por e-mail. 


8.18.Adquiera una copia de ISO 9001 e ISO 9000-3. Prepa- 
re una presentación que trate tres requisitos ISO 9001 y cómo 
se aplican en el contexto del software. 


Sanders, J., Software Quality: A Framework for Success 
in Sofiware Developrnent, Addison-Wesley, 1994, 


Sumner, F. H. Software Quality Assurance, MacMillan, 
1993. 


Wallmuller, E., Software Quality Assurance: A Practical 
Approach, Prentice-Hall, 1995. 


Weinberg, G. M., Quality Software Managenzent, 4 vols,, 
Dorset House, 1992, 1993, 1994 y 1996. 


Wilson, R. C., Software Rx: Secrets of Engineering Qua- 
lity Sofiware, Prentice-Hall, 1997. 


Una antología editada por Wheeler, Bryczynsky y Mee- 
son (Software Inspection: Industry Best Practice, IEEE Com- 
puter Society Press, 1996) presenta información útil sobre 
esta importante actividad de GCS. Friedman y Voas (Software 
Assessment, Wiley, 1995) estudian los soportes y métodos 
prácticos para asegurar la fiabilidad y la seguridad de pro- 
gramas de computadora. 

Musa (Software Reliability Engineering: More Reliable 
Software, Faster Development and Testing, McGraw-Hill, 
1998) ha escrito una guía práctica para aplicar a las técnicas 
de fiabilidad del software. Han sido editadas antologías de 
artículos importantes sobre la fiabilidad del software por Kapur 
y otros (Contrihutionsto Hardware and Software Reability 
Modelling, World Scientific Publishing Co., 1999), Gritzails 
(Reliability, Quality and Safety of Software-Intensive Systems, 
Kluwer Academic Publishing, 1997), y Lyu (Handbook of 
Software Reliahility Engineering, McGraw-Hill, 1996). Sto- 
rey (Safety-Critical Computer Systems, Addison-Wesley, 
1996) y Leveson [LEV95] continúan siendo los estudios más 
completos sobre la seguridad del software publicados hasta 
la fecha. 

Además de [SHI86], la técnicapoka-yoke para el software 
de prueba de errores es estudiada por Shingo (TheShingo Pro- 
duction Management System: Improving Product Quality by 
Preventing Defects, Productivity Press, 1989) y por Shimbun 
(Poka-Yoke: Improving Product Quulity by Preventing Defects, 
Productivity Press, 1989). 

En Intemet están disponibles una gran variedad de fuen- 
tes de información sobre la garantía de calidad del software, 
fiabilidad del software y otros temas relacionados. Se puede 
encontrar una lista actualizada con referencias a sitios (pági- 
nas) web que son relevantes para la calidad del software en 
http://www.pressman5.com. 
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CAPÍTULO 


GESTIÓN DE LA CONFIGURACIÓN 
DEL SOFTWARE (GCS/SCM)* 


UANDO se construye software de computadora, los cambios son inevitables. Además, 

los cambios aumentan el grado de confusión entre los ingenieros del software que están 

trabajando en el proyecto. La confusión surge cuando no se han analizado los cambios 
antes de realizarlos, no se han registrado antes de implementarlos, no se les han comunicado a 
aquellas personas que necesitan saberlo o no se han controlado de manera que mejoren la cali- 
dad y reduzcan los errores. Babich [BAB86] se refiere a este asunto cuando dice: 


El arte de coordinar el desarrollo de software para minimizar...la confusión, se denomina gestión de con- 
figuración. La gestión de configuración es el arte de identificar, organizar y controlar las modificaciones que 
sufre el software que construye un equipo de programación. La meta es maximizar la productividad mini- 
mizando los errores. 


La gestión de configuración del software (GCS) es una actividad de autoprotección que se 
aplica durante el proceso del software. Como el cambio se puede producir en cualquier momen- 
to, las actividades de GCS sirven para (1) identificar el cambio, (2) controlar el cambio, (3) 
garantizar que el cambio se implementa adecuadamente y (4) informar del cambio a todos aque- 
llos que puedan estar interesados. 

Es importante distinguir claramente entre el mantenimiento del software y la gestión de con- 
figuración del software. El mantenimiento es un conjunto de actividades de ingeniería del soft- 
ware que se producen después de que el software se haya entregado al cliente y esté en 
funcionamiento. La gestión de configuración del software es un conjunto de actividades de 
seguimiento y control que comienzan cuando se inicia el proyecto de ingeniería del software y 
termina sólo cuando el software queda fuera de la circulación. 


VISTAZO RÁPIDO 


¿Qué es? Cuando construimossoftwarede ¿Por qué es importante?Si no con- quenecesitan conocer los cambiosson 


computadora, surgen cambios. Debido 
aesto, necesitamos controlarlos eficaz- 
mente. La gestión de la configuración 
del software (GCS) es un conjunto de 
actividadesdiseñadas para controlarel 
cambio identificando los productos del 
trabajo que probablemente cambien, 
estableciendo relaciones entre ellos, 
definiendomecanismos para gestionar 
distintas versiones de estos productos, 
controlando los cambios realizados, y 
auditando einformandode los cambios 
realizados. 


¿Quién lo hace? Todos aquellos que 


estén involucrados en el proceso de 
ingeniería de software están relacio- 
nados con la GCS hasta cierto punto, 
perolas posiciones de mantenimiento 
especializadas son creadas a veces 
para la gestión del proceso de GCS. 


trolamos el cambio, él nos controlará a 
nosotros. Y esto nunca es bueno. Es 
muy fácil para un flujo de cambios 
incontrolados llevar al caos a un pro- 
yecto de software correcto. Por esta 
razón, la GCS esuna parte esencial de 
una buena gestión del proyecto y una 
práctica formal de la ingeniería del 
software. 


¿Cuáles son los pasos? Puesto que 


muchos productos de trabajo se obtie- 
nen cuando se construye el software, 
cada uno debe estar identificado uní- 
vocamente. Una vez que esto se ha 
logrado, se pueden establecer los 
mecanismos para el control del cam- 
bio y de las versiones. Para garantizar 
que se mantiene la calidad mientras 
se realizan los cambios, se audita el 
proceso. y paraasegurar que aquellos 


* En inglés, Software Configuration Management. 
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informados, se realizan los informes. 


¿Cuál es el producto obtenido? El 


Plan de Gestión de la Configuración 
del Software define la estrategia del 
proyecto para la GCS. Además, cuan- 
do se realiza la GCS formal, el proce- 
so de control del cambio provoca 
peticiones de cambio del software e 
informes de órdenes de cambios de 
ingeniería. 


¿Cómo puedo estar seguro de que lo 


he hecho correctamente? Cuando 
cualquier producto de trabajo puede 
ser estimado para ser supervisado y 
controlado: cuando cualquier cambio 
pueda ser seguido y analizado; cuan- 
docualquiera quenecesite saberalgo 
sobre algún cambio ha sido informa- 
do, lo habremos realizado correcta- 
mente. 


www.elsolucionario.net 


INGENIERÍA DEL SOFTWARE. U.s aora 


UNA a ara 


El resultado del proceso de ingeniería del software es 
una información que se puede dividir en tres amplias 
categorías: (1) programas de computadora (tanto en for- 
ma de código fuente como ejecutable), (2) documentos 
que describen los programas de computadora (tanto téc- 
nicos como de usuario) y (3 )datos (contenidos en el pro- 
grama o externos a él). Los elementos que componen 
toda la información producida como parte del proceso 
de ingeniería del software se denominan colectivamen- 
te configuración del software. 

A medida que progresa el proceso del software, el 
número de elementos de configuración del software 
(ECSs) crece rápidamente. Una especificación del sis- 
tema produce un plan del proyecto del software y una 
especificación de requisitos del software (así como 
otros documentos relativos al hardware). A su vez, 
éstos producen otros documentos para crear una jerar- 
quía de información. Si simplemente cada ECS pro- 
dujera otros ECSs, no habría prácticamente confusión. 
Desgraciadamente, en el proceso entra en juego otra 
variable —el cambio —. El cambio se puede producir 
en cualquier momento y por cualquierrazón. De hecho, 
la Primera Ley de la Ingeniería de Sistemas [BER80] 
establece: Sin importar en qué momento del ciclo de 
vida del sistema nos encontremos, el sistema cambia- 
rá y el deseo de cambiarlo persistirá a lo largo de todo 
el ciclo de vida. 


No hay nada permarente excepto el cambio 
rádito, 500 AdC. 


¿Cuál es el origen de estos cambios? La respuesta a 
esta pregunta es tan variada como los cambios mismos. 
Sin embargo, hay cuatro fuentes fundamentales de cam- 
bios: 


e nuevos negocios o condiciones comerciales que dic- 


tan los cambios en los requisitos del producto o en 
las normas comerciales; 


nuevas necesidades del cliente que demandan la 
modificación de los datos producidos por sistemas 
de información, funcionalidades entregadas por pro- 
ductos o servicios entregados por un sistema basado 
en computadora; 


reorganización O crecimiento/reducción del negocio 
que provoca cambios en las prioridades del proyecto 
o en la estructuradel equipo de ingeniería del software; 


restricciones presupuestarias o de planificación que 
provocan una redefinición del sistema O producto. 


La gestión de configuración del software (GCS) es un 
conjunto de actividades desarrolladas para gestionar los 
cambios a lo largo del ciclo de vida del software de com- 
putadora. 
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la mayoría de los cambiasson justificados. No lamente 
las cambios. Mejor dicho, esté seguro que tiene 
los mecanismos preparodos poro realizarlos. 


9.1.1. Líneas base 


Una línea base es un concepto de gestión de configura- 

ción del software que nos ayuda a controlar los cam- 

bios sin impedir seriamente los cambios justificados. La 

IEEE (Estándar IEEE 610.12-1990) define una línea 
base como: 

Una especificación o producto que se ha revisado formal- 

mente y sobre los que se ha llegado a un acuerdo, y que de ahí 

en adelante sirve como base para un desarrollo posterior y que 


puede cambiarse solamente a través de procedimientos for- 
males de control de cambios. 


Una forma de describir la línea base es mediante una 
analogía: 

Considere las puertas de la cocina en un gran restaurante. 

Para evitar colisiones, una puerta esta marcada como SALIDA 


y la otracomo ENTRADA. Las puertas tienen topes que hacen 
que sólo se puedan abrir en la dirección apropiada. 


Siun camarero recoge un pedido en la cocina, lo coloca en 
una bandeja luego se da cuenta de que ha cogido un plato equi- 
vocado, puede cambiar el plato correctorápida e informalmente 
antes de salir de la cocina. 


Sin embargo, si abandona la cocina, le da,el plato al 
cliente y luego se le informa de su error, debe seguir el 
siguiente procedimiento: (1) mirar en la orden de pedido si 
ha habido algún error; (2)disculparse insistentemente; (3) 
volver a la cocina por la puerta de ENTRADA; (4) expli- 
car el problema, etc. 


a 

e 

VE 

Un producto de trabajo de la ingeniería 


del software se convierte en una línea base, 
solamente después de haber sido revisado y aprobado. 


Una línea base es análoga a la cocina de un restau- 
rante. Antes de que un elemento de configuración de 
software se convierta en una línea base, el cambio se 
puede llevar a cabo rápida e informalmente. Sin embar- 
go, una vez que se establece una línea base, pasamos, 
de forma figurada, por una puerta de un solo sentido. 
Se pueden llevar a cabo los cambios, pero se debe apli- 
car un procedimiento formal para evaluar y verificar 
cada cambio. 

En el contexto de la ingeniería del software, defini- 
mos una línea base como un punto de referencia en el 
desarrollo del software que queda marcado por el envío 
de uno o más elementos de configuración del software 
y la aprobación del ECS obtenido mediante una revi- 
sión técnica formal (Capítulo 8). Por ejemplo, los ele- 
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mentos de una Especificación de Diseño se documen- 
tan y se revisan. Se encuentran errores y se corrigen. 
Cuando todas las partes de la especificaciónse han revi- 
sado, corregido y aprobado, la Especificación de Dise- 
ño se convierteen una línea base. Sólo se pueden realizar 
cambios futuros en la arquitectura del software (docu- 
mentado en la Especificación de Diseño) tras haber sido 
evaluados y aprobados. Aunque se pueden definir las 
líneas base con cualquier nivel de detalle, las líneas base 
más comunes son las que se muestran en la Figura 9.1. 


Consuo 


Asegúrese que la base de datos del proyecta se montiene 
sobre un entornocontrolado, centralizado. 


La progresión de acontecimientosque conducen a un 
línea base está también ilustrada en la Figura 9.1. Las 
tareas de la ingeniería del software producen uno o más 
ECSs. Una vez que un ECS se ha revisado y aprobado, 
se coloca en una base de datos del proyecto (también 
denominada biblioteca del proyecto o depósito de soft- 
ware). Cuando un miembro del equipo de ingeniería del 
software quiere hacer modificacionesen un ECS de línea 
base, se copia de la base de datos del proyecto a un área 
de trabajo privada del ingeniero. Sin embargo, este ECS 
extraído puede modificarse sólo si se siguen los contro- 
les GCS (tratados más adelante en este capítulo). Las 
flechas punteadas de la Figura 9.1 muestran el camino 
de modificación de una línea base ECS. 


modificada 


Base de datos del proyecto 


aprobada | 


Y 

Tareas Revisiones 

- 4engeniería » » técnicas 
del software formales 

A 4 
almacenada 
103 
extraída 
controles. 


GCS 


(0 LÍNEAS BASE: 
Especificacion del sistema 
Requisitos del software 
Especificaciones de diseño 
Código fuente 
US] Planes/ Procedimientos! 
Datos de prueba 
Sistema de funcionamiento 


FIGURA 9.1. ECS de línea base y base de datos del proyecto. 


9.12, Elementos de configuración del software 


Ya hemos definido un elemento de configuración del soft- 
ware como la información creada como parte del proce- 
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so de ingeniería del software. Llevado al extremo, se pue- 
de considerar un ECS como una sección individual de 
una gran especificación O cada caso de prueba de un gran 
conjunto de pruebas. De forma más realista, un ECS es 
un documento, un conjunto completo de casos de prue- 
ba o un componente de un programa dado (p. ej., una fun- 
ción de C++ o un paquete de ADA). 

En realidad, los ECSs se organizan como objetos de 
configuración que han de ser catalogados en la base de 
datos del proyecto con un nombre único. Un objeto de 
configuración tiene un nombre y unos atributos y está 
«conectado» a otros objetos mediante relaciones. Da acuer- 
do con la Figura 9.2, los objetos de configuración, Espe- 
cificación de Diseño, modelo de datos, componenteN, 
código fuente y Especificaciónde Prueba, están defini- 
dos por separado. Sin embargo, cada objeto está relacio- 
nado con otros como muestran las flechas. Una flecha 
curvada representa una relación de composición.Es decir, 
modelo de datos y componente N son parte del objeto 
Especificación de Diseño. Una flecha recta con dos pun- 
tas representauna interrelación.Si se lleva a cabo un cam- 
bio sobre el objeto código fuente, las interrelaciones 
permiten al ingeniero de software determinar qué otros 
objetos (y ECSs) pueden verse afectados. 


Elementos de configuración del software. 


FIGURA 9.2. Objetos de configuración. 


1 Estas relaciones se tratan en la Sección 9.2.1 y la estructura de la 
base de datos del proyecto se trata con detalle en el Capítulo 31. 
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GCS 


La gestión de configuración del softwarees un elemento 
importante de garantía de calidad del software. Su res- 
ponsabilidad principal es el control de cambios. Sin 
embargo, la GCS también es responsable de la identi- 
ficación de ECSs individuales y de las distintas versio- 
nes del software, de las auditorías de la configuración 
del software para asegurar que se desarrollan adecua- 
damente y de la generación de informes sobre todos los 
cambios realizados en la configuración. 


Referencia 


Las páginas amarillas de gestión de configuración 
contienenel listado más complejode los recursos de GCS 
en la web. Para más información, consultar: 
www.cs.colorado.edu/ users /andre/ 
tonfiguration—managementhtml 


Cualquier estudiode la GCS plantea una serie de pre- 
guntas complejas: 


¿Cómo identifica y gestiona una organización las 
diferentes versiones existentes de un programa (y su 
documentación) de forma que se puedan introducir 
cambios eficientemente? 


¿Cómo controla la organización los cambios antes 
y después de que el software sea distribuido al 
cliente? 


¿Quién tiene la responsabilidad de aprobar y de asig- 
nar prioridades a los cambios? 


¿Cómo podemos garantizar que los cambios se han 
llevado a cabo adecuadamente? 


¿Qué mecanismo se usa para avisar a otros de los 
cambios realizados? 


Estas cuestiones nos llevan a la definición de cinco 
tareas de GCS: Identificación, control de versiones, con- 
trol de cambios, auditorías de configuración y genera- 
ción de informes. 


Para controlar y gestionar los elementos de configura- 
ción, se debe identificar cada uno de forma Única y lue- 
go organizarlos mediante un enfoque orientado a objetos. 
Se pueden identificar dos tipos de objetos [CHO89]: obje- 
tos básicos y objetos compuestos”. Un objeto básico es 
una «unidad de texto» creado por un ingeniero de soft- 
ware durante el análisis, diseño, codificación o pruebas. 
Por ejemplo, un objeto básico podría ser una sección de 
una especificación de requisitos, un listado fuente de un 
módulo o un conjunto de casos prueba que se usan para 
ejercitar el código. Un objeto compuesto es una colec- 
ción de objetos básicos y de otros objetos compuestos. 
De acuerdo con la Figura 9.2, la Especificación de Dise- 
no es un objeto compuesto. Conceptualmente, se puede 
ver como una lista de referencias con nombre (identifi- 
cadas) que especifican objetos básicos, tales como mode- 
lo de datos y componente N. 

Cada objeto tiene un conjunto de características dis- 
tintas que le identifican de forma Única: un nombre, una 
descripción,una lista de recursos y una «realización». El 
nombre del objeto es una cadena de caracteres que iden- 
tifica al objeto sin ambigiedad. La descripción del obje- 
to es una lista de elementos de datos que identifican: 


+ el tipo de ECS (por ejemplo: documento, programa, 
datos) que está representado por el objeto; 
un identificador del proyecto; 


la información de la versión y/o el cambio; 


2 Como mecanismos para representar una versión completa de la 
configuración del software se ha propuesto el concepto de objeto 
agregado [GUS89] 
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Las relaciones establecidos entre los objetos de 
configuraciónpermiten al ingeniero del software 
evaluar el impacto del cambio. 


Los recursos son «entidades que proporciona, proce- 
sa, referencia o son, de alguna otra forma, requeridas por 
el objeto». [CHO89], por ejemplo, los tipos de datos, las 
funciones específicase incluso los nombres de las varia- 
bles pueden ser considerados recursos de objetos. La rea- 
lización es una referencia a la «unidad de texto» para un 
objeto básico y nulo para un objeto compuesto. 

La identificación del objeto de configuración tam- 
bién debe considerar las relaciones existentes entre los 
objetos identificados. Un objeto puede estar identifica- 
do como <parte-de> un objeto compuesto. La relación 
<parte-de> define una jerarquía de objetos. Por ejem- 
plo, utilizando esta sencilla notación 


Diagrama E-R 1.4<parte-de> modelo de datos; 
Modelo de datos <parte-de> especificación de diseño; 


creamos una jerarquía de ECSs. 

No es realista asumir que la Única relación entre los 
objetos de lajerarquía de objetos se establece median- 
te largos caminos del árboljerárquico. En muchos casos, 
los objetos están interrelacionados entre ramas de la 
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jerarquía de objetos. Por ejemplo, el modelo de datos 
está interrelacionadocon los diagramas de flujo de datos 
(suponiendo que se usa el análisis estructurado) y tam- 
bién está interrelacionado con un conjunto de casos de 
prueba para una clase particular de equivalencia. Las 
relaciones a través de la estructura se pueden represen- 
tar de la siguiente forma: 


Modelo de datos <interrelacionado> modelo de flujo de 
datos; 

Modelo de datos <interrelacionado> caso de prueba de la 
clase m; 


Referencia cruzada 


tos modelos de datos y los diagromasde flujo de datos 
se tratan en el Capítulo 12, 


En el primer caso, la interrelación es entre objetos 
compuestos, mientras que en el segundo caso, la rela- 
ción es entre un objeto compuesto (modelo de datos) 
y un objeto básico (caso de prueba de la clase m). 

Las interrelaciones entre los objetos de configura- 
ción se pueden representar con un lenguaje de interco- 
nexión de módulos (LIM) [NAR87]. Un LIM describe 
las interdependencias entre los objetos de configuración 
y permite construir automáticamente cualquier versión 
de un sistema. 

El esquema de identificación de los objetos de soft- 
ware debe tener en cuenta que los objetos evolucio- 
nan a lo largo del proceso de ingeniería del software. 
Antes de que un objeto se convierta en una línea base, 
puede cambiar varias veces,.e incluso cuando ya es 
una línea base, los cambios se presentan con bastante 
frecuencia. Se puede crear un grafo de evolución 
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[GUS89] para cualquier objeto. El grafo de evolución 
describe la historia de los cambios de un objeto y apa- 
rece ilustrado en la Figura 9.3. El objeto de configu- 
ración 1.0 pasa la revisión y se convierte en el objeto 
1.1. Algunas correcciones y cambios mínimos produ- 
cen las versiones 1.1.1 y 1.1.2, que van seguidas de 
una actualización importante, resultando el objeto 1.2. 
La evolución de objeto 1.0 sigue hacia 1.3 y 1.4, pero, 
al mismo tiempo, una gran modificación del objeto 
produce un nuevo camino de evolución, la versión 2.0. 
A estas dos versiones se les sigue dando soporte. 

Se pueden realizar cambios en cualquier versión, 
aunque no necesariamente en todas. ¿Cómo puede el 
desarrollador establecerlas referencias de todos los com- 
ponentes, documentos, casos de prueba de la versión 
1,4,? ¿Cómo puede saber el departamento comercial los 
nombres de los clientes que en la actualidad tienen la 
versión 2.1.? ¿Cómo podemos estar seguros de que los 
cambios en el código fuente de la versión 2.1 han sido 
reflejados adecuadamente en la correspondiente docu- 
mentación de diseño? Un elemento clave para respon- 
der a todas estas preguntas es la identificación. 


Herramientas CASEGCS 


Se han desarrollado varias herramientas automáticas 
para ayudaren la tarea de identificación (y otras de GCS). 
En algunos casos, se diseña la herramienta para mantener 
copias completas de las versiones más recientes. 


El control de versiones combina procedimientos y herra- 
mientas para gestionar las versiones de los objetos de 
configuración creados durante el proceso del software. 
Clemm [CLE89] describe el control de versiones en el 
contexto de la GCS: 


Consuof). 


Elesquema que Vd. estableció poro losECS debería 
incorporar el número de versión. 


La gestión de configuración permite a un usuario especifi- 
carconfiguracionesalternativasdel sistemade softwaremedian- 
te la selección de las versiones adecuadas. Esto se puede 
gestionar asociando atributos a cada versión del software y per- 
mitiendo luego especificar [y construirJuna configuración des- 
cribiendo el conjunto de atributos deseado. 


Los «atributos» que se mencionan pueden ser tan 
sencillos como un número específico de versión aso- 
ciado a cada objeto o tan complejos como una cadena 
de variables lógicas (indicadores) que especifiquen 
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tipos de cambios funcionales aplicados al sistema 
[LIES9]. 


FIGURA 9.3. Grato de evolución. 


Una representación de las diferentes versiones de un 
sistema es el grafo de evolución mostrado en la Figura 
9.3. Cada nodo del grafo es un objeto compuesto, es 
decir, una versión completa del software. Cada versión 
del software es una colección de ECSs (código fuente, 
documentos, datos) y cada versión puede estar com- 
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puesta de diferentes variantes. Para ilustrar este concep- 
to, consideremos una versión de un sencillo programa 
que está formado por los componentes 1, 2, 3, 4 y 5*, El 
componente 4 sólo se usa cuando el software se imple- 
menta para monitores de color. El componente5 se imple- 
menta cuando se dispone de monitor monocromo. Por 
tanto, se pueden definir dos variantes de la versión: (1) 
componentes l, 2, 3 y 4; (2) componentes 1, 2, 3 y 5. 

Para construir la variante adecuada de una determina- 
da versión de un programa, a cada componente se le asig- 
na una «tupla de atributos» —una lista de características 
que definen si se ha de utilizar el componente cuando se va 
a construiruna determinada versión del software — A cada 
variante se le asigna uno o más atributos. Por ejemplo, se 
podría usar un atributo colorpara definir qué componentes 
se deben incluirpara soporte de monitores en color. 


incluso un cambio para mejor, 
lo por desventajas y 


Otra forma de establecer los conceptos de la relación 
entre componentes, variantes y versiones (revisiones) 
es representarlas como un fondo de objetos [REI89]. De 
acuerdo con la Figura 9.4, la relación entre los objetos 
de configuración y los componentes, las variantes y las 
versiones se pueden representar como un espacio tridi- 
mensional. Un componente consta de una colección de 


La realidad del control de cambio en un contexto moder- 


no de ingeniería de software ha sido bien resumida por 
James Bach [BAC98] : 


El control de cambio es vital. Pero las fuerzas que lo hacen 
necesario tambien lo hacen molesto. Nos preocupamos por el 
cambio porque una diminuta perturbacion en el código puede 
crear un gran fallo en el producto. Pero tambien puede reparar 
un gran fallo o habilitar excelentescapacidadesnuevas. Nos preo- 
cupamos por el cambio porque un desarrollador pícaro puede 
hacer fracasarel proyecto; sin embargo las brillantesideas naci- 
das en la mente de estos pícaros, y un pesado proceso de con- 
trol de cambio pueden disuadirle de hacer un trabajo creativo. 


Bach reconoce que nos enfrentamos a una situacion 
a equilibrar. Mucho control de cambio y crearemos pro- 
blemas. Poco, y crearemos otros problemas. 

En un gran proyecto de ingeniería de software, el cam- 
bio incontrolado lleva rápidamenteal caos. Para estos pro- 


3 En este contexto, el término «componente» se refiere a todos los 
objetos compuestos y objetos básicos di: un ESC de línea base. Por 
ejemplo, un componente de «entrada» puede estar constituido por 
seis componentes de software distintos, cada uno responsable de 
una subfunción de entrada. 
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objetos del mismo nivel de revisión. Una variante es 
una colección diferente de objetos del mismo nivel de 
revisión y, por tanto, coexiste en paralelo con otras 
variantes. Una nueva versión se define cuando se reali- 
zan cambios significativos en uno o más objetos. 

En la pasada década se propusieron diferentes enfo- 
ques automatizados para el control de versiones. La prin- 
cipal diferencia entre los distintos enfoques está en la 
sofisticación de los atributos que se usan para construir 
versiones y variantes específicas de un sistema y en la 
mecánica del proceso de construcción. 


variantes 


entidades 
(componentes) 
A » 


versiones 


FIGURA 9.4. Representación en fondo de objetos 
de loscomponentes, variantes y versiones 


[REI89]. 


AAA 


Cita: 
del progreso está en mantener el orden en 
el cambio y mantener el cambio en medio 


yectos, el control de cambios combina los procedimien- 
tos humanos y las herramientas automáticas para propor- 
cionar un mecanismo para el control del cambio. El 
proceso de control de cambios está ilustrado esquemáti- 
camente en la Figura 9.5. Se hace una petición de cam- 
bio* y se evalúa para calcular el esfuerzo técnico, los 
posibles efectos secundarios, el impacto global sobre otras 
funciones del sistema y sobre otros objetos de la confi- 
guración. Los resultados de la evaluación se presentan 


4 Aunque muchas de las peticiones de cambio se reciben durante la 
fase de mantenimiento, en este estudio tomamos un punto de vista 
más amplio. Una petición de cambio puede aparecer en cualquier 
momento durante el proceso del software. 
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como un informe de cambios a la autoridad de control de 
cambios (ACC) —una persona o grupo que toma la deci- 
sión final del estado y la prioridad del cambio —. Para cada 
cambio aprobado se genera una orden de cambio de inge- 
niería (OCT). La OCT describe el cambio a realizar, las res- 
tricciones que se deben respetar y los criterios de revisión 
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y de auditoría. El objeto a cambiar es «dado de baja» de 
la base de datos del proyecto; serealiza el cambio y se apli- 
can las adecuadas actividades de SQA. Luego, el objeto 
es «dado de alta» en la base de datos y se usan los meca- 
nismos de control de versiones apropiados (Sección 9.4) 
para crear la siguiente versión del software. 


Se reconoce la necesidad del cambio 


El usuario suscribe la petición de cambio 
El desarrollador la evalua 


+ 
Se genera un informe de cambios 
La autoridad de control de cambios decide 


La petición queda pendiente de actúación, 


se genera la OCI 


Asignación personalizada a los objetos 


de configuración 


Petición de cambio denegada 
Información del usuario 


"Dar de baja" objetos (sidmbitos) de configuración 


Realización del cambio 
Revisión de cambio (auditoría) 


Los elementos de configuración que han cambiado son "dados de alta" 


Establecimiento de una línea base para la prueba 


Realización de actividades de garantía de calidad y de prueba 


Promoción" de los cambios para ser incluidos en la siguiente versión (revisión) 


Reconstrucción de la versión adecuada del software 


Revisión (auditoría) de los cambios en todos los elementos de configuración 


Cambios incluidos en la nueva versión 


Distribución de la nueva versión 


FIGURA 9.5. El proceso de control de cambios. 


Objeto de configuración 
(versión modificada) 
Desbloqueo 
Información de 

auditoría 


ingeniero Control 


Xx 
Objeto de configuración 


(versión de línea base) 


Información 
de pertenencia 


Base de datos 


de software de acceso 


Objeto de configuración Bloqueo 


(versión extraída) z 


Baja 


FIGURA 9.6. Control de acceso y de sincronización. 


del proyecto 


Objeto de configuración 


(versión de línea base) 
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dad 


Cons: 


la confusión conducea los errores - algunas de ellas 
muy serías — Los controles de acceso 

y desincronización evitan la confusión. Implemente 
ambos, inclusa sisu enfoque tiene que ser simplificado 
para adaptarlo a su cultura de desarrolla. 


Los procesos de «alta» y «baja» implementan dos 
elementos importantes del control de cambios --con- 
trol de acceso y control de sincronización —. El control 
de acceso gobierna los derechos de los ingenieros de 
software a acceder y modificar objetos de configuración 
concretos. El control de sincronización asegura que los 
cambios en paralelo, realizados por personas diferen- 
tes, no se sobreescriben mutuamente [HAR89]. 

El flujo de control de acceso y de sincronización están 
esquemáticamente ilustrados en la Figura 9.6. De acuer- 
do con una petición de cambio aprobada y una OCI, un 
ingeniero de software da de baja a un objeto de configu- 
ración. Una función de control de acceso comprueba que 
el ingeniero tiene autoridad para dar de baja el objeto, y 
el control de sincronización bloquea el objeto en la base 
de datos del proyecto, de forma que no se puedan hacer 
más actualizaciones hasta que se haya reemplazado con 
la nueva versión. Fíjese que se pueden dar de baja otras 
copias, pero no se podrán hacer otras actualizaciones. El 
ingeniero de software modifica una copia del objeto de 
línea base, denominada versión extraída, Tras la SQA y 
la prueba apropiada, se da de alta la versión modificada 
del objeto y se desbloquea el nuevo objeto de línea base. 

Puede que algunos lectores empiecen a sentirseincó- 
modos con el nivel de burocracia que implica el proceso 
anterior. Esta sensaciónes normal. Sin la protección ade- 
cuada, el control de cambios puede ralentizar el progre- 
so y crear un papeleo innecesario. La mayoría de los 
desarrolladores de software que disponen de mecanis- 
mos de control de cambios (desgraciadamentela mayo- 
ría no tienen ninguno) han creado varios niveles de control 
para evitar los problemas mencionados anteriormente. 


Consuo 


Optepar un poco más de controlde cambio 
del que pensaba necesitar en un principia. ES probable 
que muchapuedo ser la cantidad apropiada. 


Antes de que un ECS se convierta en una línea 
base, sólo es necesario aplicar un control de cambios 
informal. El que haya desarrollado el ECS en cues- 
tión podrá hacer cualquier cambio justificado por el 
proyecto y por los requisitos técnicos (siempre que 
los cambios no impacten en otros requisitos del sis- 
tema más amplios que queden fuera del ámbito de tra- 
bajo del encargado del desarrollo). Una vez que el 
objeto ha pasado la revisión técnica formal y ha sido 
aprobado, se crea la línea base. Una vez que el ECS 
se convierte en una línea base, aparece el control de 
cambios a nivel de proyecto. Ahora, para hacer un 
cambio, el encargado del desarrollo debe recibir la 
aprobación del gestor del proyecto (si el cambio es 
«local») O de la ACC si el cambio impacta en otros 
ECSs. En algunos casos, se dispensa de generar for- 
malmente las peticiones de cambio, los informes de 
cambio y las OCI. Sin embargo, hay que hacer una 
evaluación de cada cambio así como un seguimiento 
y revisión de los mismos. 

Cuando se distribuye el producto de software a los 
clientes, se instituye el control de cambios formal. El 
procedimiento de control de cambios formal es el que 
aparece definido en la Figura 9.5. 

La autoridad de control de cambios (ACC) desem- 
peña un papel activo en el segundo y tercer nivel de 
control. Dependiendo del tamaño y de las caracterís- 
ticas del proyecto de software, la ACC puede estar 
compuesta por una persona —el gestor del proyec- 
to— O por varias personas (por ejemplo, represen- 
tantes del software, del hardware, de la ingeniería de 
las bases de datos, del soporte o del departamento 
comercial, etc.). El papel de la ACC es el de tener una 
visión general, o sea, evaluar el impacto del cambio 
fuera del ECS en cuestión. ¿Cómo impactará el cam- 
bio en el hardware? ¿Cómo impactará en el rendi- 
miento? ¿Cómo alterará el cambio la percepción del 
cliente sobre el producto? ¿Cómo afectará el cambio 
a la calidad y a la fiabilidad? La ACC se plantea estas 
y otras muchas cuestiones. 


lo es inevitable, excepto 
máquinas de venta. 
Sticker 


La identificación, el control de versiones y el control de 
cambios ayudan al equipo de desarrollo de software a 
mantener un orden que, de otro modo, llevaría a una 
situación caótica y sin salida. Sin embargo, incluso los 
mecanismos más correctos de control de cambios hacen 
un seguimiento al cambio sólo hasta que se ha genera- 
do la OCI. ¿Cómo podemos asegurar que el cambio se 
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ha implementado correctamente? La respuesta es doble: 
(1) revisiones técnicas formales y (2) auditorías de con- 
figuración del software. 

Las revisiones técnicas formales (presentadas en deta- 
lle en el Capítulo 8) se centran en la corrección técnica 
del elemento de configuración que ha sido modificado. 
Los revisores evalúan el ECS para determinar la con- 
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sistencia con otros ECSs, las omisiones O los posibles 
efectos secundarios. Se debe llevar a cabo una revisión 
técnica formal para cualquier cambio que no sea trivial. 

Una auditoría de configuración del software com- 
plementa la revisión técnica formal al comprobar carac- 
terísticas que generalmente no tiene en cuenta la 
revisión. La auditoría se plantea y responde las siguien- 
tes preguntas: 


Cuáles son las principales 
preguntas que hacemos en 
una auditoría de configuración? 


1, ¿Se ha hecho el cambio especificado en la OCT? ¿Se 
han incorporado modificaciones adicionales? 


2. ¿Se ha llevado a cabo una revisión técnica formal 
para evaluar la corrección técnica? 
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3. ¿Se ha seguido el proceso del software y se han apli- 
cado adecuadamente los estándares de ingeniería del 
software? 


. ¿Se han «resaltado» los cambios en el ECS? ¿Se han 
especificado la fecha del cambio y el autor? ¿Reflejan 
los cambios los atributosdel objeto de Configuración? 


¿Se han seguido procedimientos de GCS para seña- 
lar el cambio, registrarlo y divulgarlo? 


. ¿Se han actualizado adecuadamente todos los ECSs 
relacionados? 


En algunos casos, las preguntas de auditoría se inclu- 
yen en la revisión técnica formal. Sin embargo, cuando 
la GCS es una actividad formal, la auditoría de la GCS 
se lleva a cabo independientemente por el grupo de 
garantía de calidad. 


La generación de informes de estado de la configura- 
ción (a veces denominada contabilidad de estado)es 
una tarea de GCS que responde a las siguientes pre- 
guntas: (1) ¿Qué pasó? (2) ¿Quién lo hizo? (3)¿Cuán- 
do pasó? (4) ¿Qué más se vio afectado? 

En la Figura 9.5 se ilustra el flujo de información 
para la generación de informes de estado de la confi- 
guración (IEC).Cada vez que se asigna una nueva iden- 
tificación a un ECS o una identificación actualizada se 
genera una entrada en el IEC. Cada vez que la ACC 
aprueba un cambio (o sea, se expide una OCT), se gene- 
ra una entrada en el IEC. Cada vez que se lleva a cabo 
una auditoría de configuración, los resultados aparecen 
como parte de una tarea de generación de un IEC. La 
salida del IEC se puede situar en una base de datos inte- 
ractiva [TAY85] de forma que los encargados del desa- 
rrollo o del mantenimiento del software puedan acceder 
a la información de cambios por categorías clave. Ade- 
más, se genera un IEC regularmente con intención de 
mantener a los gestores y a los profesionales al tanto de 
los cambios importantes. 


Cono 


Desarrolle una «lista que se necesitaconocer» 
para cada£CS y manténgalo actualizada. Cuando 
se realice un cambio, asegúrese que se informa 

a todos los queestán en la listo. 


La generación de informes de estado de la configura- 
ción desempeñaun papel vital en el éxito del proyecto de 
desarrollo de software. Cuandoaparece involucradamucha 
gente es muy fácil que se dé el síndrome de que «la mano 
izquierda ignora lo que hace la mano derecha». Puede que 
dos programadores intenten modificarel mismo ECS con 
intenciones diferentes y conflictivas. Un equipo de inge- 
niería del software puede emplear meses de esfuerzo en 
construirun software a partir de unas especificacionesde 
hardware obsoletas. Puede que la persona que descubra 
los efectos secundarios senos de un cambio propuesto no 
esté enterada de que el cambio se está realizando. El IEC 
ayuda a eliminar esos problemas, mejorando la comuni- 
cación entre todas las personas involucradas. 


La gestión de configuración del software es una activi- 
dad de protección que se aplica a lo largo de todo el pro- 
ceso del software. La GCS identifica, controla, audita e 
informa de las modificaciones que invariablemente se 
dan al desarrollar el software una vez que ha sido dis- 
tribuido a los clientes. Cualquier información produci- 
da como parte de la ingeniería del software se convierte 
en parte de una configuración del software. La confi- 
guración se organiza de tal forma que sea posible un 
control organizado de los cambios. 
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La configuración del software está compuesta por un 
conjunto de objetos interrelacionados, también deno- 
minados elementos de configuración del software, que 
se producen como resultado de alguna actividad de inge- 
niería del software. Además de los documentos, los pro- 
gramas y los datos, también se puede poner bajo control 
de configuración el entorno de desarrollo utilizado para 
crear el software. 

Una vez que se ha desarrollado y revisado un obje- 
to de configuración, se convierte en una línea base. Los 
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cambios sobre un objeto de línea base conducen a la 
creación de una nueva versión del objeto. La evolución 
de un programa se puede seguir examinando el histo- 
rial de las revisiones de todos los objetos de su confi- 
guración. Los objetos básicos y los compuestos forman 
un asociación de objetos que refleja las variantes y las 
versiones creadas. El control de versiones es un con- 
junto de procedimientos y herramientas que se usan para 
gestionar el uso de los objetos. 

El control de cambios es una actividad procedi- 
mental que asegura la calidad y la consistencia a medi- 
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9.1. ¿Por qué es cierta la primera ley de la ingeniería de sis- 
temas? ¿Cómo afecta a nuestra percepción de los paradigmas 
de la ingeniería del software? 


9.2. Exponga las razones de la existencia de líneas base con 
sus propias palabras. 


9.3. Asuma que es el gestor de un pequeño proyecto. ¿Qué 
líneas base definiría para el proyecto y cómo las controlaría? 


9.4. Diseñe un sistema de base de datos que permita a un 
ingeniero del software guardar, obtener referencias de forma 
cruzada, buscar, actualizar, cambiar, etc., todos los elemen- 
tos de la configuración del software importantes. ¿Cómo 
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da que se realizan cambios en los objetos de la con- 
figuración. El proceso de control de cambios comien- 
za con una petición de cambio, lleva a una decisión 
de proseguir o no con el cambio y culmina con una 
actualización controlada del ECS que se ha de 
cambiar. 

La auditoría de configuración es una actividad de 
SQA que ayuda a asegurar que se mantiene la calidad 
durante la realización de los cambios. Los informes de 
estado proporcionan información sobre cada cambio a 
aquellos que tienen que estar informados. 
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mo programa? ¿Se manejaría de forma diferente el código 
fuente que la documentación? ¿Cómo se evitaría que dos pro- 
gramadores hicieran cambios diferentes sobre el mismo ECS 
al mismo tiempo? 


9.5. Investigue un poco sobre bases de datos orientadas a 
objetos y escriba un artículo que describa cómo se podrían 
usar en el contexto de la GCS. 


9.6. Utilice un modelo E-R (Capítulo 12) para describir las 
interrelaciones entre los ECS (objetos) de la Sección 9.1.2. 


9.7. Investigue sobre herramientas de GCS existentes y des- 
criba cómo implementan el control de versiones, de cambios 
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9.8. Las relaciones «parte-de» e «interrelacionado» repre- 
sentan relaciones sencillas entre los objetos de configuración. 
Describa cinco relaciones adicionales que pudieran ser Utiles 
en el contexto de la base de datos del proyecto. 


9.9. Investigue sobre una herramienta de GCS existente y 
describa cómo implementa los mecanismos de control de ver- 
siones. Alternativamente,lea dos o tres de los artículos a los 
que se hace referencia en este capítulo e investigue en las 
estructurasde datos y los mecanismosque se usan para el con- 
trol de versiones. 
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9.10. Utilizando la Figura 9.5 como guía, desarrolle un 
esquema de trabajo más detallado aún para el control de cam- 
bios. Describa el papel de la ACC y sugiera formatos para la 
petición de cambio, el informe de cambios e IEC. 


9.11. Desarrolle una lista de comprobaciones que se pueda 
utilizar en las auditorías de configuración. 


9.,12.¿Cuál esla diferencia entre una auditoria de GCS y una 
revisión técnica formal? ¿Se pueden juntar sus funciones en 
una sola revisión? ¿Cuáles son los pros y los contras? 


Uno de los pocos libros escritos sobre la GCS en los últimos 
años lo realizaron Brown et al. (AntiPatterns and Patterns in 
Software Configuration Managernent, Wiley, 1989). 

Los autores tratan las cosas que no hay que hacer (anti- 
patrones) cuando se implementa un proceso de GCS y enton- 
ces consideran sus remedios. 

Lyon(Practical CM: Best Configuration Management 
Practicesfor the 21% Century, Raven Publishing, 1999) y 
Mikkelsen y Pherigo (Practical Software Configuration 
Management: The Latenight Developer's Handhook, Allyn €z 
Bacon, 1997) proporcionan tutoriales practicos importantes 
de GCS. Ben-Menachem (Software Configuration Manage- 
ment Guidebook, McGraw-Hill, 1994), Vacca (Implementing 
aSuccessful. Configuration. Change. Management. Program, 
1.5. Management Group, 1993), y Ayer y Patrinnostro (Soft- 
ware Configuration Management, McGrawHill, 1992) pre- 
sentan correctas visiones para aquellos que todavia no se han 
introducido en la materia. Berlack (Software Configuration 
Management, Wiley, 1992, presenta una estudio Util de con- 
ceptos de la GCS, haciendo incapié en la importancia del dic- 
cionario de datos (repository) y de las herramientas en la 
gestion del cambio. Babich [BAB86] es un tratado abrevia- 
do, aunque eficaz, de temas practicos sobre la gestión de con- 
figuración del software. 

Buckley (Implementing Configuration Managernent, IEEE 
Computer Society Press, 1993) estudia enfoques de gestión 
de configuraciónpara todos los elementos de un sistema (hard- 
ware, software y firmware con unos detallados tratamientos 
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de las principales actividades de GC). Rawlings (SCM for 
Network Development Environments, McGraw-Hill, 1994) 
es el primer libro de GCS en tratar el asunto con un énfasis 
específico en el desarrollo de software en un entorno de red. 
Whitgift (Methods and Toolsfor Software Configuration 
Management, Wiley, 1991)contiene una razonable cobertu- 
ra de todos los temas importantes de GCS, pero se distingue 
por su estudio del diccionario de datos y tratamiento de aspec- 
tos de entornos CASE. Arnold y Bohner (Software Change 
Impact Analysis, IEEE Computer Society Press, 1996) han 
editado una antología que estudia cómo analizar el impacto 
del cambio dentro de sistemas complejos basados en soft- 
ware. 

Puesto que la GCS identifica y controla documentos de 
ingenieria del software, los libros de Nagle (Handbookfor 
Preparing Engineering Documents: From Concept to Com- 
pletion, IEEE, 1996), Watts (Engineering Documentation 
Control Handbook: Configuration Managementfo r Industry, 
Noyes Publication, 1993). Ayer y Patnnnostro (Documenting 
the Software Process, McGraw-Hill, 1992) proporciona un 
complemento con textos mas centrados en la GCS. La edi- 
ción de Marzo de 1999 de Crosstalk contiene vanos artícu- 
los Útiles de la GCS. 

En Internet están disponibles una gran variedad de fuen- 
tes de información relacionadas con temas de gestión y de 
software. Se puede encontrar una lista actualizada con refe- 
rencias a sitios (páginas) web que son relevantes para el Soft- 
ware en http://www.pressman5.com. 
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METODOS CONVENCIONALES 
PARA LA INGENIERÍA 
DEL SOFTWARE 


mos los conceptos técnicos, métodos y mediciones que son aplicables 


E N esta parte de Ingeniería del Sofiware Un EnfoquePrácticaconsidera- 


al análisis, diseño y pruebas del software. En los capítulos siguientes; 


aprenderás las respuestas a las siguientes cuestiones: 


¿Cómo se define el software dentro del contexto de un gran sistema y qué 
papel juega la ingeniería de sistemas? 


¿Cuáles son los principios y conceptos básicos que se aplican al análisis 
de requisitos del software? 


¿Que es el análisis estructurado y cómo sus diferentes modelos te permi- 
ten entender las funciones, datos y comportamientos? 


¿Cuáles son los conceptos básicos y los principiosque se aplican en la acti- 
vidad de diseño del software? 


¿Cómo se realiza el diseño de los modelos de datos; arquitectura, interfa- 
ces y componentes? 


¿Cuáles son los conceptos básicos, principios y estrategias que se aplican 
a las pruebas del software” 


:Cómo se utilizan los métodos de prueba de caja negra y caja blanca para 
diseñar eficientes casos de prueba? 


¿Qué métricas técnicas están disponibles para valorar la calidad de los 
modelos de análisis y diseño, código fuente y casos de prueba? 


Una vez que estas cuestiones sean contestadas, comprenderás cómo cons- 


truir software utilizando un enfoque disciplinado de ingeniería. 
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CAPÍTULO 


10 INGENIERÍA DE SISTEMAS 


ACE casi 500 años, Maquiavelo dijo: «... no hay nada más difícil de llevar a cabo, más 

peligroso de realizar o de éxito más incierto que tomar el liderazgo en la introducción 

de un nuevo orden de cosas». Durante los Últimos 50 años, los sistemas basados en com- 
putadora han introducido un nuevo orden. Aunque la tecnología ha conseguido grandes avan- 
ces desde que habló Maquiavelo, sus palabras siguen sonando a verdad. 

La ingeniería del software aparece como consecuencia de un proceso denominado ingenie- 
ría de sistemas. En lugar de centrarse únicamente en el software, la ingeniería de sistemas se 
centra en diversos elementos, analizando, diseñando y organizando esos elementos en un sis- 
tema que pueden ser un producto, un servicio o una tecnología para la transformación de infor- 
mación o control de información. 

El proceso de ingeniería de sistemases denominado ingenieríade procesos de negocio cuando 
el contexto del trabajo de ingeniería se enfoca a una empresa. Cuando hay que construir un pro= 
ducto, el proceso se denomina ingeniería de producto. 

Tanto la ingeniería de proceso de negocio como la de producto intentan poner orden al desa- 
rrollo de sistemas basados en computadoras. Aunque cada una se aplica en un dominio de apli- 
cación diferente, ambas intentan poner al software en su contexto. 


VISTAZO RÁPIDO 


ns ¿Qué es? Antes de que el software se pue- es el sistema, y los árboles son los ele- ¿Cuál es el producto obtenido? Se debe 


da construir, el «sistema» en el que 
residirá se debe comprender. Para 
lograrlo, se deben definir los objetivos 
generalesdel sistema;se debeidenti- 
ficar el papel del hardware, software, 


personas, bases de datos, procedi-' 


mientos y otros elementos del sistema; 
y los requerimientos operacionales 
deben ser identificados; analizados, 
especificados,modelizados, validados 
y gestionados. Estas actividades son 
la base de la ingeniería de sistemas. 


¿Quién lo hace? Un ingeniero de sistemas 


trabaja para comprender los requisitos 
del sistema en colaboración con el 
cliente, los futuros usuarios y otras par- 
tes interesadas. 


¿Por qué es importante? Hay un viejo dicho 


que dice que «los árboles no dejan ver 
el bosque». En este contexto, el «bosque» 


mentos tecnológicos (incluido el soft- 
ware) que son requeridos para realizar 
el sistema. El empeño en construir ele- 
mentos tecnológicos, antes de com- 
prender el sistema, lleva a cometer 
errores que desagradarán a los clientes. 


¿Cuáles son los pasos? Los objetivos y 
los requisitos operacionales de mayor * 


detalle son identificados gracias a la 
información facilitada por el cliente. 
Los requisitos son analizados para 
valorar su claridad, completitud y 
consistencia. Una especificación, 
incorporada a un modelo del sistema, 
se crea y valida posteriormente por 
los clientes y las partes interesadas. 
Finalmente, los requisitos del siste- 
ma son gestionados para asegurar 
que los cambios se controlan ade- 
cuadamente. 


obtener una correcta representación 
del sistema como consecuencia de la 
ingeniería de sistemas. Se puede rea- 
lizar a través de un prototipo, una 
especificación o, incluso, un modelo 
simbólico, debiendo comunicar la 
operativa, la funcionalidad y las 
características de comportamiento del 
sistema que se va a construir e incor- 
porarlo dentrc de la arquitectura del 
sistema. 


¿Cómo puedo estar seguro de que lo he 


hecho correctamente? El producto obte- 
nido, a través de la aplicación de la 
ingeniería de sistemas, debe ser revi- 
sado para determinar su claridad, com- 
pletitud y consistencia. Es importante 
que los cambios en los requisitos de un 
sistema sean gestionados utilizando 
métodos sólidos de GCS (Capítulo9). 


Es decir, tanto la ingeniería de procesos de negocio' como la de producto trabajan para asignar un 
papel al software de computadora y para establecer los enlaces que unen al software con otros ele- 
mentos de un sistema basado en computadora. 

En este capítulo, profundizamos en las necesidades de gestión y en las actividades específicas del 
proceso que permitan asegurar una organización del software que consiga resultados satisfactoriosen 
el tiempo fijado y por el método definido. 


! En realidad, el término ingeniería de sistemas se emplea a menudo en este contexto. Sin embargo, en este libro, el 
término «ingeniería de sistemas» es genérico y se usa para abarcar a la ingeniería de proceso de negocio y a la inge- 
niería de producto. 
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La palabra sistema es posiblemente el término más usa- 
do y abusado del léxico técnico. Hablamos de sistemas 
políticos y de sistemas educativos, de sistemas de avia- 
ción y de sistemas de fabricación, de sistemas banca- 
rios y de sistemas de locomoción. La palabra no nos 
dice gran cosa. Usamos el adjetivo para describir el sis- 
tema y para entender el contexto en que se emplea. El 
diccionario Websterdefine sistema como: 

1, un conjuntoo disposición de cosas relacionadas de mane- 
ra que forman una unidad o un todo orgánico; 2. un conjunto 
de hechos, principios, reglas, etc., clasificadas y dispuestas de 
manera ordenadamostrandoun plan lógico de unión de las par- 
tes; 3. un método o plan de clasificacióno disposición; 4.una 
manera establecida de hacer algo; método; procedimiento... 


Se proporcionan cinco definiciones más en el dic- 
cionario, pero no se sugiere un sinónimo preciso. Sis- 
tema es una palabra especial. 

Tomando prestada la definición del diccionario Webs- 
ter, definimos un sistema basado en computadora como: 

Un conjunto o disposición de elementos que están organi- 
zados para realizar un objetivo predeñinido procesando infor- 
mación. 

El objetivo puede ser soportar alguna función de 
negocio o desarrollar un producto que pueda venderse 
para generar beneficios. Para conseguir el objetivo, un 
sistema basado en computadora hace uso de varios ele- 
mentos del sistema: 

Software.Programas de computadora, estructuras de datos 


y su documentación que sirven para hacer efectivo el método 
lógico, procedimiento o control requerido. 


Hardware. Dispositivos electrónicos que proporcionan 
capacidad de cálculo, dispositivos de interconexión (por 
ejemplo, conmutadores de red, dispositivos de telecomuni- 
cación) y dispositivos electromecánicos (por ejemplo, sen- 
sores, motores, bombas) que proporcionan una función 
externa, del mundo real. 


Personas. Usuarios y operadores del hardware y software. 


Documentación. Manuales, formularios y otra informa- 
ción descriptiva que plasma el empleo y/o funcionamiento 
del sistema. 


Procedimientos. Los pasos que definen el empleo especí- 
fico de cada elemento del sistema o el contexto procedimental 
en que reside el sistema. 


Rons:ofH) 


No esté atraído por hablar de un planteamiento 
«centrado en el software». Comience por considerar 
todos los elementos de un sistema antes de concentrarse 
enel software. 


Los elementos se combinan de varias maneras para 
transformar la información. Por ejemplo, un departamento 
de marketing transforma la información bruta de ventas 
en un perfil del típico comprador del producto; un robot 
transforma un archivo de órdenes, que contiene instruc- 


ciones específicas, en un conjunto de señales de control 
que provocan alguna acción física específica. Tanto la 
creación de un sistema de información para asesorara un 
departamentode marketing, como el softwarede control 
para el robot, requieren de la ingeniería de sistemas. 

Una característica complicada de los sistemas basa- 
dos en computadora es que los elementos que compo- 
nen un sistema pueden también representar un 
macroelemento de un sistema aún más grande. El macro- 
elemento es un sistema basado en computadora que es 
parte de un sistema más grande basado en computado- 
ra. Por ejemplo, consideremos un «sistema de automa- 
tización de una fábrica» que es esencialmente una 
jerarquía de sistemas. En el nivel inferior de la jerar- 
quía tenemos una máquina de control numérico, robots 
y dispositivos de entrada de información. Cada uno es 
un sistema basado en computadora por derecho propio. 
Los elementos de la máquina de control numérico inclu- 
yen hardware electrónico y electromecánico (por ejem- 
plo, procesador y memoria, motores, sensores); software 
(para comunicaciones, control de la máquina e interpo- 
lación); personas (el operador de la máquina); una base 
de datos (el programa CN almacenado); documentación 
y procedimientos. Se podría aplicar una descomposi- 
ción similar a los dispositivos de entrada de informa- 
ción y al robot. Todos son sistemas basados en 
computadora. 


a 
a 
ER VE 


los sistemas complejosson actualmente uno jerarquía 
de macro elementos que son sistemas en sí mismos. 


En el siguiente nivel de la jerarquía, se define una 
célula de fabricación. La célula de fabricaciónes un sis- 
tema basado en computadora que puede tener elemen- 
tos propios (por ejemplo, computadoras, fijaciones 
mecánicas) y también integra los macroelementos que 
hemos denominado máquina de control numérico, robot 
y dispositivo de entrada de información. 

Para resumir, la célula de fabricación y sus macroe- 
lementos están compuestos de elementos del sistema 
con las etiquetas genéricas: software, hardware, perso- 
nas, base de datos, procedimientos y documentación. 
En algunos casos, los macroelementos pueden compartir 
un elemento genérico. Por ejemplo, el robot y la máqui- 
na CN podrían ser manejadas por el mismo operador 
(el elemento personas). En otros casos, los elementos 
genéricos son exclusivos de un sistema. 

El papel del ingeniero de sistemas es definir los ele- 
mentos de un sistema específico basado en computa- 
dora en el contexto de la jerarquía global de sistemas 
(macroelementos). 

En las siguientes secciones, examinamos las tareas que 
constituyen la ingeniería de sistemas de computadoras. 
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Dominio 


de negocio 
o de producto 


mn no 


Dominio de interés 


Elemento 
del sistema 


Independientemente del dominio de enfoque, la ingenie- 
ría de sistemas comprende una colección de métodos para 
navegar de arriba abajo y de abajo arriba en la jerarquía 
ilustrada en la Figura 10.1, El proceso de la ingeniería de 
sistemas empieza normalmente con una «visión global». 
Es decir, se examina el dominio entero del negocio o del 
producto para asegurarse de que se puede establecer el 
contexto de negocio o tecnológico apropiado. La visión 
global se refina para enfocarse totalmente en un dominio 
de interés específico. Dentro de un dominioespecífico, se 
analiza la necesidad de elementos del sistema (por ejem- 
plo, información, software, hardware, personas). Final- 
mente, se inicia el análisis, diseño y construcción del 
elemento del sistema deseado. En la parte alta de la jerar- 
quía se establece un contexto muy amplio y en la parte 
baja se llevan a cabo actividades técnicas detalladas,rea- 
lizadas por la disciplina de ingeniería correspondiente(por 
ejemplo, ingeniería hardware o software”. 


102.1. Modelado del sistema 


La ingeniería de sistemas de computadora es un proce- 
so de modelado. Tanto si el punto de mira está en la 


visión global o en la visión detallada, el ingeniero crea 
modelos que [MO'T'92]: 


2 En algunas situaciones, sin embargo, los ingenieros del sistema 
deben considerar primero los elementos individuales del sistema y/o 
los requisitos detallados. Empleando este enfoque, los subsistemas 
se escriben de abajo a arriba considerando primero los componen- 
tes de detalle del subsistema. 
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Vista global 


Vista 
del dominic 


Vista 
del elemento 


Vista 
detallada 


definan los procesos que satisfagan las necesidades 
de la visión en consideración; 

representen el comportamiento de los procesos y los 
supuestos en los que se basa el comportamiento; 
definan explícitamente las entradas exógenas? y endó- 
genas de información al modelo; 

representen todos las uniones (incluyendo las sali- 
das) que permitan al ingeniero entender mejor la 


visión. 
US 
Ga 
VE 


tos buenos sstarres de ingeniería comienzan por 
clarificar el comportamiento de contexto —la visión 


global — y progesvamente se van estrechando hesa 
el nivel de detale necesario. 


Para construir un modelo del sistema, el ingeniero 
debería considerar algunas restricciones: 


1, Supuestos que reducen el número de permutaciones 
y variaciones posibles, permitiendo así al modelo 
reflejar el problema de manera razonable. Por ejem- 


3 Las entradas exógenas unen un elemento de una visión dada con 
otros elementos al mismo o a otros niveles; las entradas endógenas 
unen componentes individuales de un elemento en una visión par- 
ticular. 
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plo, considere un producto de representación en tres 
dimensiones usado por la industria de entretenimiento 
para crear animaciones realistas. Un dominio del pro- 
ducto permite la representación de formas humanas 
en 3D. Las entradas a este dominio comprenden la 
habilidad de introducir movimiento de un «actor» 
humano vivo, desde vídeo o creando modelos gráfi- 
cos. El ingeniero del sistema hace ciertos supuestos 
sobre el rango de movimientos humanos permitidos 
(por ejemplo, las piernas no pueden enrollarse alre- 
dedor del tronco) de manera que puede limitarse el 
proceso y el rango de entradas. 


. Simplificaciones que permiten crear el modelo a 
tiempo. Para ilustrarlo, considere una compañía de 
productos de oficina que vende y suministra una 
amplia variedad de fotocopiadoras, faxes y equipos 
similares. El ingeniero del sistema está modelando 
las necesidades de la organización suministradora y 
está trabajando para entender el flujo de información 
que engendra una orden de suministro. Aunque una 
orden de suministro puede generarse desde muchos 
orígenes, el ingeniero categoriza solamente dos fuen- 
tes: demanda interna O petición externa. Esto per- 
mite una partición simplificada de entradas necesaria 
para generar una orden de trabajo. 


. Limitaciones que ayudan a delimitar el sistema. Por 
ejemplo, se está modelando un sistema de aviónica 
para un avión de próxima generación. Como el avión 
tendrá un diseño de dos motores, todos los dominios 
de supervisión de la propulsión se modelarán para 
albergar un máximo de dos motores y sus sistemas 
redundantes asociados. 


Restricciones que guían la manera de crear el modelo 
y el enfoque que se toma al implementar el modelo. 
Por ejemplo, la infraestructura tecnológica para el 
sistema de representación en tres dimensiones des- 
crita anteriormente es un solo procesador basado en 
un Power-PC. La complejidad de cálculo de los pro- 
blemas deben restringirse para encajar en los lími- 
tes de proceso impuestos por el procesador. 


e 
CLA VE 


Un ingeniero del sistema consideralos siguientes factores 
cuando desarrolla soluciones alternativas: planteamientos, 
simplificaciones, limitaciones, restriccionesy preferencias 
de los clientes. 


¿Dónde acaba el modelo 
de ingeniería del sistema? 


4. 


. Preferencias que indican la arquitectura preferida 
para todos los datos, funciones y tecnología. La solu- 
ción preferida entra a veces en conflicto con otros 
factores restrictivos. Aunque la satisfacción del 
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cliente es a menudo tomada en cuenta hasta el punto 
de realizar su enfoque preferido. 


El modelo de sistema resultante (desde cualquier 
visión) puede reclamar una solución completamente 
automática, semiautomática o un enfoque manual. De 
hecho, es posible a menudo caracterizar modelos de 
cada tipo que sirven de soluciones alternativas para el 
problema que tenemos entre manos. En esencia, el 
ingeniero del sistema modifica simplemente la influen- 
cia relativa de los diferentes elementos del sistema 
(personas, hardware, software) para crear modelos de 
cada tipo. 


10.2.2. Simulación del sistema 


En los años 60, R.M. Graham [GRA69] hizo un comen- 
tario crítico sobre la manera en que se construían los sis- 
temas basados en computadora: «Construimos sistemas 
igual que los hermanos Wright construían aviones: cons- 
truimos todo el sistema, lo empujamos barranco abajo, 
le dejamos que se estrelle y empezamos de nuevo.» De 
hecho, para al menos un tipo de sistema —el sistema 
reactivo — lo continuamos haciendo hoy en día. 

Muchos sistemas basados en computadora interac- 
cionan con el mundo real de forma reactiva. Es decir, 
los acontecimientos del mundo real son vigilados por 
el hardware y el software que componen el sistema, y 
basándose en esos sucesos, el sistema aplica su control 
sobre las máquinas, procesos e incluso las personas que 
motivan los acontecimientos. Los sistemas de tiempo 
real y sistemas empotrados pertenecen a menudo a la 
categoría de sistemas reactivos. 


Cons:of) 


Silo capacidad de simulación no está disponible 

poro un sistema reactivo, el riesgo del proyecto 

se incremento. Considerar poro su utilización: un modelo 
deproceso ¡terafivo que te permito obtener un resultado 
en uno primero iteración y utilizar otras iteraciones poro 
ajustar sus características. 


Desgraciadamente, los desarrolladores de sistemas 
reactivos luchan a veces para hacerlos funcionar correc- 
tamente. Hasta hace poco, ha sido difícil predecir el ren- 
dimiento, la eficacia y el comportamiento de estos 
sistemas antes de construirlos. Realmente, la construc- 
ción de muchos sistemas de tiempo real era una aven- 
tura. Las sorpresas (la mayoría desagradables) no se 
descubrían hasta que el sistema era construido y «arro- 
jado colina abajo». Si el sistema se estrellaba debido a 
un funcionamiento incorrecto, comportamiento inapro- 
piado o escasorendimiento, cogíamos las piezas y empe- 
zábamos de nuevo. 

Muchos sistemas de la categoríade los reactivos con- 
trolan máquinas y/o procesos (por ejemplo, aerolíneas 
comerciales o refinerías de petróleo) que deben operar 
con extrema fiabilidad. 
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Si el sistema falla, podrían ocurrir pérdidas econó- 
micas O humanas significativas. Por este motivo, el enfo- 
que descrito por Graham es penoso y peligroso. 

Hoy en día se utilizan herramientas software para 
el modelado y simulación de sistemas para ayudar a 
eliminar sorpresas cuando se construyen sistemas 
reactivos basados en computadora. Estas herramien- 
tas se aplican durante el proceso de ingeniería de sis- 
temas, mientras se están especificando las necesidades 
del hardware, software, bases de datos y de personas. 
Las herramientas de modelado y simulación capaci- 
tan al ingeniero de sistemas para probar una especi- 
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ficación del sistema. En el Capítulo 31 se estudian 
brevemente los detalles técnicos y técnicas especia- 
les de modelado que se emplean para llevar a cabo 
estas pruebas. 


Herramientas CASE 
Modelado y Simulación 


El objetivo de la ingeniería de proceso de negocio (IPN) 
es definir arquitecturas que permitan a las empresas 
emplear la información eficazmente. Michael Guttman 
[GUT99] describe el desafio cuando dice: 


El actual entorno computacional consiste en un poder de 
computación distribuido en toda la empresa con múltiples 
unidades diferentes de procesamiento, dividido y configura- 
do por una amplía variedad de tareas, Nuevos planteamien- 
tos como la computación cliente-servidor, procesamiento 
distribuido, el trabajo en red (por nombrar algunos de los tér- 
minos más sobreusados) permiten gestionar las demandas 
aportando mayor funcionalidad y flexibilidad. 


Sin embargo, el coste de estos cambios es ampliamente 
discutido por la organizacionesde 71 (Tecnologías de la Infor- 
mación) que deben soportar esta políglota configuración. 
Hoy, cada organización de TI debe favorecer la integración 
de sus sistemas. Debe diseñar, implementar y soportar su 
propia configuración de recursos de computación heterogé- 
nea, distribuidos lógica y geográficamente por toda la empre- 
sa, conectándola a través de un esquema apropiado para el 
trabajo en red. 


Por otra parte, esta configuración debe ser diseñada para 
cambios continuos, desigualmente localizadosen la empre- 
sa, debido a cambios en requisitos del negocio y en las pro- 
pias tecnologías. Estos diversos e incrementales cambios 
deben ser coordinados a través del entorno distribuido, con- 
sistente en hardware y software suministrado por decenas, 
cuando no cientos, de vendedores. Por supuesto, esperamos 
que estos cambios los incorporemos sin ruptura con la ope- 
rativa habitual permitiendo además ampliar la operativa. 


Cuando hablamos de una visión general de las nece- 
sidades de tecnología de información de una compañía, 
existen pequeñas incertidumbres que son planteadas a 
la ingeniería de sistemas. La ingeniería de proceso de 
Begocio es un acercamiento para crear un plan gene- 

para implementar la arquitectura de computación 


ISPE93]. 


N 
a 


CLAVE 


Tres arquitecturas diferentes son desorrollodos durante 
la FA la arquitectura de datos, la arquitectura 
de aplicación y la infraestructura tecnológica. 


Se deben analizar y diseñar tres arquitecturas dife- 
rentes dentro del contexto de objetivos y metas de 
negocio: 

» arquitectura de datos 
» arquitectura de aplicaciones 
» infraestructura de la tecnología 


Referencia cruzada 


los obietos de datos son tratodos en detalle 
en el Capítulo 12. 


La arquitectura de datos proporciona una estructu- 
ra para las necesidades de información de un negocio O 
de una función de negocio. Los ladrillos de la arquitec- 
tura son los objetos de datos que emplea la empresa. Un 
objeto de datos contiene un conjunto de atributos que 
definen aspectos, cualidades, características o descrip- 
tor de los datos que han sido descritos. Por ejemplo, un 
ingeniero de la información puede definir el objeto de 
datos: cliente. Para describir más en detalle al cliente, 
se definen los siguientes atributos: 


Objeto: Cliente 
Atributos: 
nombre 
nombre de la compañía 
clasificación del trabajo y autoridad en compra 
dirección comercial e información de contacto 
producto(s) de interés 
compra(s) anteriores 
fecha de último contacto 
situación del contacto 
Una vez definido el conjunto de datos, se identifican 
sus relaciones. Una relación indica como los objetos 
están conectados. Como ejemplo, considerar los obje- 
tos: cliente y productoA. Los dos objetos pueden conec- 
tarse por la relación compra, es decir, un cliente compra 


el producto A o el producto A es comprado por un clien- 
te. Los objetos de datos (pueden existir cientos o miles 
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para una actividad de negocio importante) fluyen entre 
las funciones de negocio, están organizados dentro de 
una base de datos y se transforman para proveer infor- 
mación que sirva a las necesidades del negocio. 

La arquitectura de aplicación comprende aquellos 
elementos de un sistema que transforman objetos den- 
tro de la arquitectura de datos por algún propósito del 
negocio. En el contexto de este libro, consideramos 
normalmente que la arquitectura de aplicación es el sis- 
tema de programas (software) que realiza esta trans- 
formación. Sin embargo, en un contexto más amplio, 
la arquitectura de aplicación podría incorporar el papel 
de las personas (por ejemplo, cliente/servidor) que ha 
sido diseñado para implementar estas tecnologías. 


Edetalle sobre la arquitectura del software 
és presentado en el Capítulo 14. 


La infraestructura tecnológica proporciona el fun- 
damento de las arquitecturas de datos y de aplicaciones. 
La infraestructura comprende el hardware y el software 
empleados para dar soporte a las aplicaciones y datos. 
Esto incluye computadoras y redes de computadora, enla- 
ces de telecomunicaciones, tecnologías de almacena- 
miento y la arquitectura (por ejemplo, cliente/servidor) 
diseñada para implementar estas tecnologías. 


Planificacion 
estratégica 
de la informacion 
(vista global) 


Área de negocio 


Análisis del área 
de negocio 
(vista 
del dominio) 


Requisito de Proceso 


MN Diseño del sistema 
de negocio 
| (vista del elemento) 


¡IM Sistema ' j q 


Ingeniería 
del 


Si software 
Construcción 


e integración 
(vista detallada) 


- 3 po... 


FIGURA 10.2. Lajerarquía de la ingeniería de procesos. 


Para modelar las arquitecturas de sistema descritas 
anteriormente, se define una jerarquía de actividades de 
ingeniería de la información. Como muestra la Figura 
10.2, la visión global se consigue a través de la planifi- 
cación de la estrategia de información (PEI). La PEI 
ve todo el negocio como una entidad y aisla los domi- 
nios del negocio (por ejemplo, ingeniería, fabricación, 
marketing, finanzas, ventas) importantes para la totali- 
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dad de la empresa. La PEI define los objetos de datos 
visibles a nivel empresa, sus relaciones y cómo fluyen 
entre los dominios del negocio [MAR9O0]1. 


Ronsuo 


lomo ingeniero del software, no debes profundizar en PEL 
ni en el AAN. No obstante, sino está cloro que estas 
actividades hayan sido realizadas, informe a su superior 
que el riesgo del proyecto es muy alto. 


La vista del dominio se trata con una actividad IPN 
denominada análisis del área de negocio (AAN).Hares 
[HAR93] describe AAN de la siguiente manera: 

El AAN se ocupa de identificaren detallela información (en 
la forma de tipos de entidad [objeto datos]) y los requisitos de 
las funciones (en la forma de procesos) de áreas de negocio 
seleccionadas [dominios] identificadas durante el PEI, averi- 
guando sus interacciones (en forma de matrices). Se ocupa sola- 
mente de especificarqué se requiere en un área de negocio. 


A medida que el ingeniero de informacióncomienza el 
AAN, el enfoque se estrecha hacia un dominio del nego- 
cio específico. El AAN ve el área del negocio como una 
entidad y aísla las funciones de negocio y procedimientos 
que permiten al área del negocio lograr sus objetivos y 
metas. El AAN, al igual que el PEL, define objetos de datos, 
sus relaciones y cómo fluye la información. Pero a este 
nivel, estas características están delimitadas por el área de 
negocio que se está analizando. El resultado de AAN es 
aislar las áreas de oportunidad en las que los sistemas de 
información pueden prestar soporte al área de negocio. 


Ingeniería de Procesos de Negocio 


Una vez que se ha aislado un sistema de información 
para un desarrollo posterior, la IPN hace una transición 
a la ingeniería del software. Invocando la fase del dise- 
ño de sistema de negocio (DSN),se modelan los requi- 
sitos básicos de un sistema de información específico y 
estos requisitos se traducen en arquitectura de datos, 
arquitectura de aplicación e infraestructura tecnológica. 

El paso final de la IPN (construcción e integración, 
C4l) se centra en los detalles de la implementación. La 
arquitectura e infraestructura se implementan constru- 
yendo una base de datos apropiada y estructuras internas 
de datos, mediante la construcción de aplicaciones que 
están constituidas por programas, y seleccionando los 
elementos apropiados de una infraestructuratecnológica 
para dar soporte al diseño creado durante el DSN. Cada 
uno de estos componentes del sistema debe integrarse 
para formar una aplicación o sistemade información com- 
pleto. La actividad de integración también coloca al nue- 
vo sistema de información en el contexto del área de 
negocio, realizando todo el entrenamiento de usuario y 
soporte logístico para conseguiruna suave transición. 
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La meta de la ingeniería de producto es traducir el 
deseo de un cliente, de un conjunto de capacidades 
definidas, a un producto operativo”. Para conseguir 
esta meta, la ingeniería de producto (como la inge- 
niería de proceso de negocio) debe crear una arqui- 
tectura y una infraestructura. La arquitectura 
comprende cuatro componentes de sistema distintos: 
software, hardware, datos (bases de datos) y perso- 
nas. Se establece una infraestructura de soporte e 
incluye la tecnología requerida para unir los compo- 
nentes y la información (por ejemplo, documentos, 
CD-ROM, vídeo) que se emplea para dar soporte a 
los componentes. 

Como se muestra en la Figura 10.3, la visión glo- 
bal se consigue a través de la ingeniería de requisi- 
tos. Los requisitos generales del producto se obtienen 
del cliente. Estos requisitos comprenden necesidades 
de información y control, funcionalidad del produc- 
to y comportamiento, rendimiento general del pro- 
ducto, diseño, restricciones de la interfaz y otras 
necesidades especiales. Una vez que se conocen estos 
requisitos, la misión del análisis del sistema es asig- 
nar funcionalidad y comportamiento a cada uno de 
los cuatro componentes mencionados anteriormente. 

Una vez que se ha hecho la asignación, comienza 
la ingeniería de componentes del sistema. La inge- 
niería de componentes del sistema es, de hecho, un 
conjunto de actividades concurrentes que se dirigen 
separadamente a cada uno de los componentes del sis- 
tema: la ingeniería del software, ingeniería hardware, 
ingeniería humana e ingeniería de bases de datos. Cada 
una de estas disciplinas de ingeniería toma una vista 
de dominio específica, pero es importante resaltar que 
las disciplinas de ingeniería deben establecer y man- 
tener una comunicación activa entre ellas. 


Análisis 
del sistema 
(vista global) 
Capacidades 
Ingenieria 
de componente 
¡ (vista 
de dominio) 
Requisito de Proceso / 
e MI Modelo de Análisis 
l ' IO lid — y Diseño (vista 
, MU MIA ] E  delelemento) 
ES e e Componentes | Ingenierí 
geniería 
E e UU EN de programa | del software 
Ll ma US Construcción 


a. sj € integración 
O 
FIGURA 10.3. La jerarquía de la ingeniería de productos. 


Parte del papel del análisis de sistemas es establecer los 
mecanismos de interfaz que permitirán que esto suceda. 

La visión de elemento para la ingeniería de produc- 
to es la disciplina de ingeniería aplicada a la asignación 
de componentes. Para la ingeniería del software, esto 
significa actividades de modelado del análisis y diseño 
(cubierto en detalle en posteriores capítulos) y activi- 
dades de construcción e integración que comprenden 
generación de código, pruebas y actividades de sopor- 
te. El modelado de la fase de análisis asigna requisitos 
a las representaciones de datos, funciones y comporta- 
miento. El diseño convierte el modelo de análisis en 
diseños de datos, arquitectónicos, de interfaz y a nivel 
de componentes del software. 


La consecuencia del proceso de ingeniería de sistemas 
es la especificación de un sistema o producto basado en 
computadora que se describe genéricamente, en dife- 
rentes niveles en la Figura 10.1. Pero el desafío de la 
ingeniería del sistema (y de los ingenieros del softwa- 
re) es importante: ¿Cómo podemos asegurar que hemos 
especificado un sistema que recoge las necesidades del 
cliente y satisface sus expectativas? No hay una res- 
puesta segura a esta difícil pregunta, pero un sólido pro- 
ceso de ingeniería de requisitos es la mejor solución de 
que disponemos actualmente. 


“Debemos hacer notar que la terminología (adaptadapor [MAR90]) 
utilizada en la Figura 10.2está asociada con la ingeniería de la infor- 
mación, la predecesora del moderno IPN. Sin embargo, el área cen- 
tral implicada en cada actividad señalada es dirigida por todos 
aquellos que consideran el tema. 
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construcción de un sistema 

o construirlo... Ninguna parte 
sultado del sistemo si está 
parte es más dificultosa pora 


La ingeniería de requisitos facilita el mecanismo 
apropiado para comprenderlo que quiere el cliente, ana- 
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lizando necesidades, confirmando su viabilidad, nego- 
ciando una solución razonable, especificando la solu- 
ción sin ambigiiedad, validando la especificación y 
gestionando los requisitos para que se transformen en 
un sistema operacional [THA97]. El proceso de inge- 
niería de requisitos puede ser descrito en 5 pasos dis- 
tintos [SOM97]: Identificación de Requisitos, Análisis 
de Requisitos y Negociación, Especificación de Requi- 
sitos, Modelizado del Sistema, Validación de Requisi- 
tos y Gestión de Requisitos. 


10.5.1. Identificación de requisitos 


En principio, parece bastante simple — preguntar al 

cliente, alos usuarios y a los que están involucrados en 

los objetivos del sistema o producto y sean expertos, 

investigar cómo los sistemas O productos se ajustan a 

las necesidades del negocio, y finalmente, cómo el sis- 

tema Oo producto va a serutilizado en el día a día— Esto 
que parece simple, es muy complicado. 

Christel y Kang [CRI92] identifican una serie de pro- 
blemas que nos ayudan a comprender por qué la obten- 
ción de requisitos es costosa. 

+ problemas de alcance. El límite del sistema está mal 
definido o los detalles técnicos innecesarios, que han 
sido aportados por los clientes/usuarios, pueden con- 
fundir más que clarificar los objetivos del sistema. 

* problemas de comprensión. Los clientes/usuarios no 
están completamente seguros de lo que necesitan, 
tienen una pobre compresión de las capacidades y 
limitacionesde su entorno de computación, no existe 
un total entendimiento del dominio del problema, 
existen dificultades para comunicar las necesidades 
al ingeniero del sistema, la omisión de información 
por considerar que es «obvia», especificación de 
requisitos que están en conflicto con las necesidades 
de otros clientes/usuarios, o especificar requisitos 
ambiguos O poco estables. 


Problemas de volatilidad. Los requisitos cambian 


con el tiempo. 
Referencia Web] ' 


Un informe detallado bajo el titulo (Necesidades 

en lu Obtención de Requisitos)) puede ser descargado de 
www.sei.cmu.edu / publications / documents / 
92.reports/92.11.012.html 


Para ayudar a solucionar estos problemas, los inge- 
nieros de sistemas deben aproximarse de una mane- 
ra organizada a través de reuniones para definir 
requisitos. 

Sommerville y Sawyer [SOM97] sugieren un con- 
junto de actuacionespara la obtención de requisitos, que 
están descritos en las tareas siguientes: 
valorar el impacto en el negocio y la viabilidad téc- 
nica del sistema propuesto; 
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¿Por qué es tan difícil 
obtener un planteamiento 
claro de lo que necesita 
el cliente? 


identificar las personas que ayudarán a especificar 
requisitos y contrastar su papel en la organización; 
definir el entorno técnico (arquitectura de computa- 
ción, sistema operativo, necesidades de telecomuni- 
caciones) en el sistema o producto a desarrollar e 
integrar; 

identificar «restricciones de dominio» (característi- 
cas específicas del entorno de negocio en el domi- 
nio de la aplicación) que limiten la funcionalidad y 
rendimientos del sistema o producto a construir; 
definir uno O más métodos de obtención de requisi- 
tos (entrevistas, grupos de trabajo, equipos de dis- 
cusión); 

solicitar la participación de muchas personas para 
que los requisitos se definan desde diferentes puntos 
de vista, asegurarse de identificar lo fundamental de 
cada requisito registrado; 

identificar requisitos ambiguos como candidatos para 
el prototipado, y 

crear escenarios de uso (ver Capítulo 11) para ayu- 
dar a los clientes/usuarios a identificar mejor los 
requisitos fundamentales. 


Cionsuo o 


Asegúrate de haber valorado los características generales 
antes de especificar el esfuerzo y plazo para obtener 
los requisitos de detalle, 


El resultado alcanzado como consecuencia de la iden- 
tificación de requisitos variará dependiendo del tama- 
ño del sistema O producto a construir. Para grandes 
sistemas, el producto obtenido debe incluir: 
una relación de necesidades y características; 
un informe conciso del alcance del sistema o producto; 
una lista de clientes, usuarios y otros intervinientes 
que deben participar en la actividad de obtención de 
requisitos; 
una descripción del entorno técnico del sistema; 
una relación de requisitos (perfectamente agrupados 
por funcionalidad) y las restricciones del dominio 
aplicables a cada uno; 
un conjunto de escenarios que permiten profundizar 
en el uso del sistema o producto bajo diferentes con- 
diciones operativas, y 
cualquier prototipo desarrollado para definir mejor 
los requisitos. 


Referencia cruzada 


los métodos de obtención de requisitos 
son presentados en el Capítulo 11, 
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Cada uno de los productos obtenidos debe ser revi- 
sado por las personas que hayan participadoen la obten- 
ción de sus requisitos. 


10.5,2, Análisis y negociación de requisitos 
Una vez recopilados los requisitos, el producto obteni- 
do configura la base del análisis de requisitos. Los requi- 
sitos se agrupan por categorías y se organizan en 
subconjuntos, se estudia cada requisito en relación con 
el resto, se examinan los requisitos en su consistencia, 
completitud y ambigijedad, y se clasifican en base a las 
necesidades de los clientes/usuarios. 

> ¿Qué cuestiones deben ser 

preguntadas y contestadas 
. durante el análisis de requisitos? 


Al iniciarse la actividad del análisis de requisitos se 
plantean las siguientes cuestiones: 

» ¿Cada requisito es consistente con los objetivos gene- 
rales del sistema/producto? 

+ ¿Tienen todos los requisitos especificados el nivel 
adecuado de abstracción? Es decir, ¿algunos requi- 
sitos tienen un nivel de detalle técnico inapropiado 
en esta etapa? 

» ¿El requisito es necesario o representa una caracte- 
rística añadida que puede no ser esencial a la finali- 
dad del sistema? 

+ ¿Cada requisito está delimitado y sin ambigitedad? 

» Cada requisito tiene procedencia. Es decir, ¿existe 
un origen (general o específico) conocido para cada 
requisito? 

+ ¿Existen requisitos incompatibles con otros requi- 
sitos? 

» ¿Es posible lograr cada requisito en el entorno téc- 
nico donde se integrará el sistema o producto? 


» ¿Se puede probar el requisito una vez implementado? 


Análisis de Requisitos 


Es corriente en clientes y usuarios solicitar más de 
lo que puede realizarse, consumiendo recursos de nego- 
cio limitados. También es relativamente común en clien- 
tes y usuarios el proponer requisitos contradictorios, 
“argumentando que su versión es «esencial por necesi- 
dades especiales». 


Consiof) 


Silos diferentes clientes /usuarios no pueden facilitar 
los requisitos, el riesgo de errar es muy alto. Proceda 
con extrema precaución. 
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El ingeniero del sistema debe resolver estos conflic- 
tos a través de un proceso de negociación. Los clientes, 
usuarios y el resto de intervinientes deberán clasificar 
sus requisitos y discutir los posibles conflictos según su 
prioridad. Los riesgos asociados con cada requisito serán 
identificados y analizados (ver Capítulo 6). Se efectúan 
«estimaciones» del esfuerzo de desarrollo que se utili- 
zan para valorar el impacto de cada requisito en el cos- 
te del proyecto y en el plazo de entrega. Utilizando un 
procedimiento iterativo, se irán eliminando requisitos, 
se irán combinando y/o modificando para conseguir 
satisfacer los objetivos planteados. 


10.5.3. Especificación de requisitos 


En el contexto de un sistema basado en computadoras 
(y software), el término especificación significa distin- 
tas cosas para diferentes personas. Una especificación 
puede ser un documento escrito, un modelo gráfico, un 
modelo matemático formal, una colección de escena- 
rios de uso, un prototipo o una combinación de lo ante- 
riormente citado. 

Algunos sugieren que debe desarrollarse una «plan- 
tilla estándar» [SOM97] y usarse en la especificación 
del sistema, argumentando que así se conseguiríanrequi- 
sitos que sean presentados de una forma más consis- 
tente y más comprensible. No obstante, en muchas 
ocasiones es necesario buscar la flexibilidadcuando una 
especificación va a ser desarrollada. Para grandes sis- 
temas, un documento escrito, combinado con descrip- 
ciones en lenguajes natural y modelos gráficos puede 
ser la mejor alternativa. En cualquier caso, los escena- 
rios a utilizar pueden ser tanto los requeridos para pro- 
ductos de tamaño pequeño o los de sistemas que residan 
en entornos técnicos bien conocidos. 


Técnicas de Negociación 


La Especificacióndel Sistema es el producto final sobre 
los requisitos del sistema obtenido por el ingeniero. Sir- 
ve como fundamento para la ingeniería del hardware, 
ingeniería del software, la ingeniería de bases de datos y 
la ingeniería humana. Describe la función y característi- 
cas de un sistema de computación y las restricciones que 
gobiernan su desarrollo. La especificación delimita cada 
elemento del sistema. La Especificación del Sistema des- 
cribe la información (datos y control) que entra y sale del 
sistema. 


Especificacióndel sistema 
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10.5.4. Modelado del sistema 


Considere por un momento que a usted se le ha reque- 
rido para especificar los requisitos para la construcción 
de una cocina. Se conocen las dimensiones del lugar, la 
localización de las puertas y ventanas y el espacio de 
pared disponible. Debes especificartodos los armarios 
y electrodomésticos e indicar dónde colocarlos. ¿Será 
una especificación válida? 

La respuesta es obvia. Para especificar completamente 
lo que vamos a desarrollar, necesitamos un modelo de 
la cocina con toda su información, esto es, un antepro- 
yecto o una representaciónen tres dimensiones que mues- 
tre las posiciones de los armarios y electrodomésticos, 
y sus relaciones. Con el modelo serárelativamente fácil 
asegurar la eficiencia del trabajo (un requisito de todas 
las cocinas), la estética «visual» de la sala (es un requi- 
sito personal, aunque muy importante). 

Se construyen modelos del sistema por la misma 
razón que desarrollamos para una cocina un antepro- 
yecto o una representación en 3D. Es importante eva- 
luar los componentes del sistema y sus relaciones entre 
sí; determinar cómo están reflejados los requisitos, y 
valorar como se ha concebido la «estética» en el siste- 
ma. Se profundiza en el modelado del sistema en la 
Sección 10.6. 


10.5.5, Validación de requisitos 


El resultado del trabajo realizado es una consecuencia 
de la ingeniería de requisitos (especificación del siste- 
ma e información relacionada) y es evaluada su calidad 
en la fase de validación. La validación de requisitos exa- 
mina las especificaciones para asegurar que todos los 
requisitos del sistema han sido establecidos sin ambi- 
giedad, sin inconsistencias, sin omisiones, que los erro- 
res detectados hayan sido corregidos, y que el resultado 
del trabajo se ajusta a los estándares establecidos para 
el proceso, el proyecto y el producto. 


Cons 


Un punto fundamental durante la validación 

de los requisitos es la consistencia. Utilice el modelo 
del sistema para asegurar que los requisitos 

har sido consistentemente establecidos. 


El primer mecanismo para la validación de los requi- 
sitos es la revisión técnica formal (Capítulo 8). El equi- 
po de revisión incluye ingenieros del sistema, clientes, 
usuarios, y otros intervinientes que examinan la espe- 
cificación del sistema? buscando errores en el conteni- 
do o en la interpretación, áreas donde se necesitan 
aclaraciones, información incompleta, inconsistencias 


5 En realidad, muchas Revisiones Técnicas Formales son dirigidas a 
medida que se desarrolla la especificación del sistema. Es mejor para 
el equipo de revisión examinar pequeñas partes de la especificación, 
de forma que se pueda centrar la atención en un aspecto específico 
de los requisitos. 
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(es un problema importante), requisitos contradictorios, 
o requisitos imposibles o inalcanzables. 

Aunque la validación de requisitos puede guiarse de 
manera que se descubran errores, es útil chequear cada 
requisito con un cuestionario. Las siguientes cuestiones 
representan un pequeño subconjunto de las preguntas 
que pueden plantearse: 


¿Está el requisito claramente definido? ¿Puede inter- 
pretarse mal? 

¿Está identificado el origen del requisito (por ejem- 
plo: persona, norma, documento)? ¿El planteamiento 
final del requisito ha sido contrastado con la fuente 
original? 

¿El requisito está delimitado en términos cuantita- 
tivos? 

¿Qué otros requisitos hacen referencia al requisito 
estudiado? ¿Están claramente identificados por medio 
de una matriz de referencias cruzadas o por cualquier 
otro mecanismo? 

¿El requisito incumple alguna restricción definida? 
¿El requisito es verificable? Sies así, ¿podemos efec- 
tuar pruebas (algunas veces llamadas criterios de 
validación) para verificar el requisito? 

¿Se puede seguir el requisito en el modelo del sis- 
tema que hemos desarrollado? 

¿Se puede localizar el requisito en el conjunto de 
objetivos del sistema/producto? 

¿Está el requisito asociado con los rendimientos del 
sistema O con su comportamiento y han sido esta- 
blecidas claramente sus características operaciona- 
les? ¿El requisito está implícitamente definido? 


3 


3 


Requisitos 


Las preguntas planteadas en la lista de comproba- 
ción ayudan a asegurar que el equipo de validación dis- 
pone de lo necesario para realizar una revisión completa 
de cada requisito. 


10.5.6. Gestión d e requisitos 


En el capítulo anterior se advertía que los requisitos del 
sistema cambian y que el deseo de cambiar los requisi- 
tos persiste a lo largo de la vida del sistema. La gestión 
de requisitos es un conjunto de actividades que ayudan 
al equipo de trabajo a identificar, controlar y seguir los 
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requisitos y los cambios en cualquier momento. Muchas 
de estas actividades son idénticas a las técnicas de ges- 
tión de configuración del software que se referencian 
en el Capítulo 9. 


Referencia Web 
Un artículo titulado ((Configurandoel trabajo de gestión 


de requisitos para fi» contiene una guía pragmático: 
stsc.hill.af.mil. /crosstalk/1999 /apr/davis.asp 


Como en la Gestión de Configuración del Software 
(GCS), la gestión de requisitos comienza con la activi- 
dad de identificación. A cada requisito se le asigna un 
Único identificador, que puede tomar la forma: 


<tipo de requisito><requisito n.* > 


El tipo de requisito toma alguno de los siguientes 
valores: F =requisito funcional, D =requisito de datos, 
C =requisitode comportamiento, / =requisito de inter- 
faz, y $ =requisito de salida. De esta forma, un requi- 
sito identificado como FO9 indica que se trata de un 
requisito funcional y que tiene asignado el número 9 
dentro de los citados requisitos. 


y 
a 
du VE 


Muchas actividades de gestión de requisitos 
son tomadas de la GOS 


Una vez los requisitos han sido identificados, se 
desarrollarán un conjunto de matrices para su segul- 
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miento. En la Figura 10.4 se muestra de forma 
esquemática este planteamiento. Cada matriz de 
seguimiento identifica los requisitos relacionados 
con uno O más aspectos del sistema o su entorno. 
Entre las posibles matrices de seguimiento citamos 
las siguientes: 


Matriz de seguimiento de características. Muestra 
los requisitos identificados en relación a las caracte- 
rísticas definidas por el cliente del sisterna/producto. 


Matriz de seguimiento de orígenes. Identifica el 
origen de cada requisito. 


Matriz de seguimiento de dependencias. Indica 
cómo se relacionan los requisitos entre sí. 


Matriz de Seguimiento de subsistemas. Vincula 
los requisitos a los subsistemas que los manejan. 


Matriz de seguimiento de interfaces. Muestra 
como los requisitos están vinculados a las interfaces 
externas O internas del sistema. 


Cons 


Cuando un sistema es grande y complejo, determinar 

las «conexiones» entre las requisitos puede ser una tarea 
desalentadora. Utilice las tablas de seguimiento 

para hacer el trabajo unpoco más fácil, 


En muchos casos, las matrices de seguimiento se 
incorporan como parte de un requisito de base de datos 
y se utiliza para buscar rápidamente los diferentes aspec- 
tos del sistema a construir afectados por el cambio de 
requisito. 


Todos los sistemas basados en computadora pueden 
modelarse como una transformación de la información 
empleando una arquitectura del tipo entrada-proceso- 
salida. Hatley y Pirbhai [HAT87] han extendido esta 
visión para incluir dos características adicionales del 
sistema: tratamiento de la interfaz de usuario y trata- 
miento del mantenimiento y autocomprobación. Aun- 
que estas características adicionales no están presentes 
entodos los sistemas basados en computadora, son muy 
comunes y su especificación hace más robusto cualquier 
modelo del sistema. 

Mediante la representación de entrada, proceso, sali- 
da, tratamiento de la interfaz de usuario y de autocom- 
probación, un ingeniero de sistemas puede crear un 
modelo de componentes de sistema que establezca el fun- 
damento para análisis de requisitos posteriores y etapas 
de diseño en cada una de las disciplinas de ingeniería. 
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Aspecto específico del sistema o de su entorno 


FIGURA 10.4. Matriz de seguimiento genérica. 
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Proceso de interfaz de usuario 


Proceso 
de entrada 


Proceso 
de salida 


Funciones de proceso 
y control 


Mantenimiento 
y autocomprobación 


FIGURA 10.5. Plantilla del modelo del sistema [HAT87]. 


Para desarrollar el modelo de sistema, se emplea un 
esquema del modelado del sistema [HAT87]. El inge- 
niero de sistemas asigna elementos a cada una de las 
cinco regiones de tratamiento del esquema: (1) interfaz 
de usuario, (2) entrada, (3 )tratamiento y control del sis- 
tema, (4) salida y (5 )mantenimiento y autocomproba- 
ción. En la Figura 10.5 se muestra el formato del 
esquema de arquitectura. 


Referencia cruzada 


Otros métodos de modelización del sistema toman 
una visión orientada a objetos. El enfoque UML puede 
ser aplicadao estos sistemas, plonteándose 

en los Capítulos 21 y 22. 


Como casi todas las técnicas de modelado usadas en 
la ingeniería del software y de sistemas, el esquema del 
modelado del sistema permite al analista crear una jerar- 
quía en detalle. En la parte alta de la jerarquía reside el 
diagrama de contexto del sistema (DCS). El diagrama 
de contexto «establece el límite de información entre el 
sistema que se está implementando y el entorno en que 
va a operar» [HAT87]. Es decir,el DCS define todos los 
suministradoresexternos de información que emplea el 
sistema, todos los consumidores externos de informa- 
ción creados por el sistema y todas las entidades que se 
comunican a través de la interfaz o realizan manteni- 
miento y autocomprobación. 

Para ilustrar el empleo del DCS, considere una ver- 
sión ampliada del sistema de clasificación de cinta trans- 
portadora (SCCT) estudiado anteriormente en el 
Capítulo 5. Al ingeniero del sistema se le presenta la 
siguiente declaración (algo confusa) de objetivos para 
el SCCT: 

El sistema SCCT debe desarrollarsede manera que las cajas 
que se mueven alo largo de la cinta transportadora sean iden- 
tificadas y ordenadas en uno de los seis contenedores al final 
de la cinta. Las cajas pasarán a través de una estación clasifi- 
cadora donde se identificarán. Basándoseen un número de iden- 
tificación impreso en un lateral de la caja (se proporciona un 
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código de barras equivalente), las cajas se mandarán a los con- 
tenedores apropiados. Las cajas pasan aleatoriamente y están 
igualmente espaciadas. La línea se mueve lentamente. 


Operador de la estación 
de clasificación 


Petición Consultas 
e informes 
Lector 

de código 


de barras 


Mecanismo 
de clasificación 


Cinta a 
transportadora | | Indicador de la 


velocidad de la cinta 


Estructura 
principal 


Operador 
de la estación 
de clasificación 


FIGURA 10.6. Diagrama de contexto de Arquitectura 
del SCCT (ampliado). 


Para este ejemplo, la versión ampliada utiliza un PC 
en la estación clasificadora. El PC ejecuta todo el software 
del SCCT,; interacciona con el lector de código de barras 
para leer parte de los números de cada caja; interacciona 
con la cinta transportadora vigilando los equipos que con- 
trolan velocidad en dicha cinta; almacenatodos los núme- 
ros de pieza clasificados; interacciona con el operador 
de la estación clasificadora para producir una variedad 
de informes y diagnósticos; envía señales de control al 
hardware separador para clasificar las cajas; y se comu- 
nica con la estructura central de la automatización de la 
fábrica. En la Figura 10.6se muestra el DCS para SCCT 
(ampliado). 


Consiofh 


ElD(S permite una visión «global» del sistema 
que debes construir. los detalles que necesites 
no deben especificarse en este nivel. Refina 
jerárquicamente el DÉS para elaborar el sistema. 


Cada caja de la Figura 10.6representa una entidad 
externa, es decir, un suministrador o consumidor de 
información del sistema. Por ejemplo, el lector del códi- 
go de barras produce información que es introducidaen 
el sistema SCCT. El símbolo para representar todo el 
sistema (O a niveles más bajos, subsistemas principa- 
les) es un rectángulo con las esquinas redondeadas. De 
ahí que SCCT se represente en la región de proceso y 
control en el centro del DCS. Las flechas etiquetadas 
mostradas en el DCS representan información (datos y 
control) que va desde el entorno exterior al sistema 
SCCT. La entidad externa lector del código de barras 
produce una entrada de información etiquetada como 
código de barras. En esencia, el DCS sitúa a cualquier 
sistema en el contexto de su entorno exterior. 
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Interfaz en 
el operador Peticiones de operador » 


Respuestas, informes y visualizacionesdel SCCT 
Subsi em 
e mte 
con a 


operador 


FT 


Procesoy control Petición 
del SCCT de informe 


Subsistema Subsistema Número Subsistema 
lector decodificador | de piezas 
de código del código de control > Controlador 


¡ de maniobras 
de barras de barras de maniobras 


—— 


Datos dE: Posición ¡ , 
del código del contenedoi] Ordenes de maniobra 


de barras Subsistema TH 


de acceso » 


a la base de datos d poncho 
. e configuración 
Velocidad de informes 
de la cinta 


Datosdi | :alización temporal 


Código de barras 


Informes de SCCT 


Subsistema 
del sensor 

de adquisición 
de datos 


Clasificación Controlador 
de registros de las 
comunicaciones 
con la computadora 
central 


sihoie 
Entrada d o. LM M/M M3 3 | 


de tacómetro AAA Estado de comunicaciones Configuración 
de impulsos de los datos 


Estado del lector del informe 


; de código de barras 
' Interfaz de adquisición a 
: de datos Interfaz de diagnóstico Interfaz de salida 


FIGURA 10.7. Diagrama de flujo de arquitectura para el SCCT (ampliado). 


ejemplo, hardware, software, personas) tal y como los 
ha asignado el ingeniero de sistemas. 
EDCS es un precursor del diagrama de lujo de delos El diagrama inicial de flujo del sistema (DES) se con- 
que se estuda en el Capíto 12. vierte en el nudo superior de una jerarquía de DES. Cada 
rectángulo redondeado del DFS original puede expan- 


El ingeniero de sistemas refina el diagrama de con- dirse en otra plantilla de arquitectura dedicada exclusi- 


texto de arquitectura estudiando con más detalle el rec- Vámente a ella. Este proceso se ilustra esquemáticamente 
tángulo sombreado de la Figura 10.6. Se identifican los en la Figura 10.8. Cada uno de los DES del sistema pub 
subsistemas principales que permiten funcionar al sis" e usarse como punto de partida de subsiguientes fases 
tema clasificador de cinta transportadora dentro del con- de ingeniería para el subsistema que se describe. 


texto definido por el DCS. En la Figura 10.7 los 
subsistemas principales se definen en un diagrama de 
flujo del sistema (DF S )que se obtiene del DCS. El flu- 


jo de información a través de las regiones del DCS se Referencia Web] 

usa para guiar al ingeniero de sistemas en el desarrollo Para congeter el métoo de Hatley-Pirbhoi se puede acudir a 

de DFS (un «esquema» más detallado del SCCT). El www.hasys.com/papers/hp_description.htmt 
diagrama de flujo de la arquitectura muestra los subsis- 

temas principales y el flujo de las líneas de información Se pueden especificar (delimitar) los subsistemas y 


importantes (datos y control). Además, el esquema del la información que fluyen entre ellos para los subsi- 
sistema divide el proceso del subsistema en cada una guientes trabajos de ingeniería. Una descripción narra- 
de las cinco regiones de proceso estudiadas anterior- tiva de cada subsistema y una definición de todos los 
mente. En este punto, cada uno de los subsistemas pue- datos que fluyen entre los subsistemas son elementos 
de contener uno o más elementos del sistema (por importantes de la Especificación del Sistema. 
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FIGURA 10.8. Construcción de una jerarquía DFA. 


Un sistema de alta tecnología comprende varios com- 
ponentes: hardware, software, personas, bases de datos, 
documentación y procedimientos. La ingeniería de sis- 
temas ayuda a traducir las necesidades del cliente en un 
modelo.de sistema que utiliza uno O más de estos com- 
ponentes. 

La ingeniería de sistemas comienza tomando una 
«visión global». Se analiza el dominio de negocio o 
producto para establecer todos los requisitos básicos. 
El enfoque se estrecha entonces a una «visión de 
dominio», donde cada uno de los elementos del sis- 
tema se analiza individualmente. Cada elemento es 
asignado a uno o más componentes de ingeniería que 
son estudiados por la disciplina de ingeniería corres- 
pondiente. 

La ingeniería de procesos de negocio es un enfoque 
de la ingeniería de sistemas que se usa para definir arqui- 
tecturas que permitan a un negocio utlizar la informa- 
ción eficazmente. La intención de la ingeniería de 
procesos de negocio es crear minuciosas arquitecturas 
de datos, una arquitectura de aplicación y una infraes- 
tructura tecnológica que satisfaga las necesidades de la 
estrategía de negocio y los objetivos de cada área de 
negocio. La ingeniería de procesos de negocio com- 


[CR192] Chnstel, M.G., y K.C. Kang, «Issuesin Requirements 
Elicitation», Software Engineering Institute, CMU/SEI- 
92-TR-127, September 1992, 


[GRA69] Graham, R.M., en Proceedings 1969 NATO Con- 
ference onSofiare Engineering, 1969. 


[GUT99] Guttman, M., «Architectural Requirements for a 
Changing Business World», Research Briefsfrom Cutter 
Consortium (an online service), June 1, 1999, 


[HAR93] Hares, J.S., Information Engineeringfor the Advan- 
ced Practitioner, Wiley, 1993,pp. 12-13. 


[HAT87] Hatley, D.J., el.A. Pirbhai, Strategiesfo r Real-Time 
System Specification, Dorset House, 1987. 
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prende una planificación de la estrategia de la infor- 
mación (PE1),un análisis del área de negocio (AAN)y 
un análisis específico de aplicación que de hecho for- 
man parte de la ingeniería del software. 

La ingeniería de productos es un enfoque de la inge- 
niería de sistemas que empieza con el análisis del sis- 
tema. El ingeniero de sistemas identifica las necesidades 
del cliente, determina la viabilidad económica y técni- 
ca, y asigna funciones y rendimientos al software, hard- 
ware, personas y bases de datos; los componente claves 
de la ingeniería. 

La ingeniería del sistema demanda una intensa 
comunicación entre el cliente y el ingeniero del siste- 
ma. Esto se realiza a través de un conjunto de activi- 
dades bajo la denominación de ingeniería de requisitos 
—identificación, análisis y negociación, especificación, 
modelización, validación y gestión—. 

Una vez que los requisitos hayan sido aislados, el 
modelado del sistema puede ser realizado, y las repre- 
sentaciones de los subsistemas principales pueden ser 
desarrolladas. La tarea de la ingeniería del sistema fina- 
liza con la elaboración de una Especificación del Siste- 
ma —un documento que sirve de base para las tareas de 
ingeniería que se realizarán posteriormente—. 


[MAR90] Martin, J., Information Engineering: Book H — 
Planning and Analysis, Prentice Hall, 1990. 


[MOT92] Motamarri, S., «Systems Modelling and Descrip- 
tion», Software Engineering Notes, vol. 17,n.? 2, Abril 
1992, pp. 57-63. 


[SOM97] Somerville, 1., y P. Sawyer, Requirements Enginee- 
ring, Wiley, 1997 

[SPE93] Spewak, S., Enterprise Architecture Planning, QED 
Publishing, 1993. 


[THA97] Thayer, R.H., y M. Dorfman, Software Require- 
ments Engineering, 2.* ed., IEEE Computer Society Press, 
1997. 
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unrinuidO 10 


10.1. Encuentre tantos sinónimos como pueda de la palabra 
«sistema». ¡Buena suerte! 


102 Construya una descripción en estructura jerárquica para 
un sistema, producto o servicio que le sea familiar. El plantea- 
miento abarcarálos elementos fundamentalesdel sistema (hard- 
ware, software, etc.) de una rama concreta de dicha estructura. 


103. Seleccione un gran sistema o producto con el que esté 
familiarizado. Defina el conjunto de dominios que describen la 
visión global de él. Describa el conjunto de elementos que com- 
pongan uno O dos dominios. Para un elemento, identifique los 
componentes técnicos con los que hay que hacer ingeniería. 


10,4, Seleccione un gran sistema o producto con el que esté 
familiarizado. Establezcalos supuestos, simplificaciones, limi- 
taciones, restricciones y preferencias que deberían haberse 
hecho para construir un modelo de sistema eficaz y realizable. 


:10,5, La ingeniería de proceso de negocio requiere definir 
datos, arquitectura.de aplicaciones, además de una infraes- 
tructura tecnológica. Describa cada uno de estos términos 
mediante un ejemplo. 


106. La planificación de la estrategía de la información empie- 
za por la definición de objetivos. Ponga ejemplos de cado uno 
de los dominios de negocio. 


10.7. Un ingeniero de sistemas puede venir de una de tres pro- 
cedencias: el desarrollo de sistemas, el cliente o una tercera 
organización. Discuta los pros y contras de cada procedencia. 
Descnba a un ingeniero de sistemas «ideal». 


108. Su profesor les repartirá una descripción de alto nivel de 
un sistema o producto. 


a. Desarrolle un conjunto de cuestiones que debería pre- 
guntar como ingeniero de sistemas. 


b. Proponga al menos dos asignaciones diferentes para el 
sistema basándose en las respuestas de su profesor a 
sus preguntas. 


c. En clase, compare sus respuestas con las de sus com- 
pañeros. 


409. Desarrolle una lista de comprobación para los atributos 
¡8 considerar cuando hay que evaluar la «viabilidad» de un sis- 
tema o producto. Estudie la interacción entre los atributos e 
intente proporcionar un método para puntuar cada uno de 
manera que se obtenga una «puntuación de viabilidad». 


10.10. Investigue las técnicas dercóntabilidad que se emplean 
para un análisis detallado de coste/beneficio de un sistema 
que requiera algo de fabricación y montaje de hardware. 
Intente escribir un libro de directrices que pueda aplicar un 
gestor técnico. 


10.11. Desarrolle el diagrama de contexto DCS y el resto de 
diagramas de flujo de un sistema a su elección (o definido por 
su profesor). 


10.12. Escriba una descripción de un módulo del sistema que 
pudiera estar contenido en la especificación de diagrama de 
arquitectura de uno o más de los subsistemas definidos en los 
DFA desarrollados para el problema 10.11, 


10.13. Investigue documentación sobre herramientas CASE 
y escriba un breve documento describiendo cómo trabajan las 
herramientas de modelado y simulación. Alternativa: Reúna 
información de dos o más vendedores de CASE que suminis- 
tren herramientas de modelado y simulación y valore las simi- 
litudes y las diferencias. 


10.14. Basándose en la documentación que le proporcione su 
profesor, desarrolle una pequeña Especificación de Sistema 
para uno de los siguientes sistemas: 


a. Un sistema de edición de vídeo digital no lineal 
b. Un escáner digital para ordenador personal 

c. Un sistema de correo electrónico 

d. Un sistema para apuntarse a la universidad 

e. Un proveedor de acceso a internet 


f. Un sistema interactivo de reserva de hoteles 


g. Un sistema de interés local 


Asegúrese de crear los modelos de arquitectura descritos en 
la Sección 10.6 


10,15, ¿Existen características de un sistema que no se pue- 
dan establecer durante las actividades de ingeniería de siste- 
mas? Describa las características, si existen, y explique por 
qué se debe retrasar su consideración a fases posteriores de la 
ingeniería. 


10.16. ¿Existen situaciones en las que se pueda abreviar o eli- 
minar completamente la especificación formal del sistema? 
Explíquelo. 


han publicado relativamente pocos libros sobre inge- 
biería de sistemas en los últimos años. Entre ellos desta- 

mos: 

Blanchard, B.S., System Engineering Management, 2." ed., 
Wiley, 1997. 

Rechtin, E., y M.W. Maier, The Art of Systems Architec- 
ging, CRC Press, 1996. 

Weiss, D., et al., Software Product-Line Engineering, Addi- 
ron-Wesley, 1999. 

Libros como los de Armstrong y Sage (Intoduction to Sys- 
léms Engineering, Wiley, 1997), Martin (Systems Enginee- 
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ring Guidehook, CRC Press, 1996), Wymore (Model-Based 
Systems Engineering, CRC Press, 1993), Lacy (SystemEngi- 
neering Management, McGraw-Hill, 1992), Aslaksen y Bel- 
cher (Systems Engineering, Prentice-Hall,1992), Athey 
(Systematic Systems Approach, Prentice-Hall, 1982), y Blan- 
chard y Fabrycky (Systems Engineering and Analysis, Pren- 
tice-Hall, 1981) presentan el proceso de la ingeniería del 
sistema (con un énfasis diferente de la ingeniería) y ofrecen 
una valiosa guía. 

En los Últimos años, los textos de ingeniería de la infor- 
mación han sido reemplazados por libros que se centran en 
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la ingeniería de proceso de negocio. Scheer (Business Pro- 
cess Engineering: Reference Modelsfor Industrial Enterpri- 
ses, Springer-Verlag, 1998) describe métodos de modelado 
de procesos de negocio para empresas con amplios sistemas 
de información. Lozinsky (Enterprise-Wide Software Solu- 
tions: Integration Strategies and Practices, Addison-Wesley, 
1998)plantea el uso de paquetes software como una solución 
que permita a una compañía migrar de los sistemas hereda- 
dos a procesos de negocio modernos. Martin (Information 
Engineering, 3 volúmenes, Prentice-Hall, 1989, 1990, 1991) 
presenta un planteamiento comprensivo sobre los tópicos de 
la ingeniería de la información. Libros como los de Hares 
[HAR93], Spewak [SPE93] y Flynn y Fragoso-Diaz (Infor- 
mation Modeling: An International Perspective, Prentice- 
Hall, 1996) tratan este tema con detalle. 

Davis y Yen (The Information system Consultant's Hand- 
book: Systems Analysis and Design, CRC Press, 1998) pre- 
sentan una cobertura enciclopédica de los resultados del 
análisis y diseño de sistemas en el dominio de los sitemas de 
información. Un volumen más reciente de los mismos auto- 
res (Standards, Guidelines and Examples: System and Soft- 


ware Requirements Engineering, IEEE Computer Society 
Press, 1990)presenta un planteamiento de estándares y direc- 
trices para el trabajo de análisis. 

Para aquellos lectores involucrados activamente en el tra- 
bajo de sistemas o interesados en un tratamiento más sofisti- 
cado sobre el tema, se propone los libros de Gerald Weinberg's 
(An Introduction to General System Thinking, Wiley- Inters- 
cience, 1976, y On the Design of Stable Systems, Wilwy- 
Interscience, 1979) permiten una excelente discusión sobre 
el «pensamiento general de sistemas» que implícitamentelle- 
va a un acercamiento general al análisis y diseño de sistemas. 
Libros más recientes son los de Weinberg (General Princi- 
pies of Systems Design, Dorset House, 1998, y Rethinking 
systems Analysis and Design, Dorset House, 1988)continúan 
en la tradición de su más avanzado trabajo. 

Una amplia variación de fuentes de información sobre inge- 
niería de sistemas y elementos relacionados están disponibles 
en intemet. Una lista actualizada de referencias a páginas web 
sobre ingeniería de sistemas, ingeniería de la información, 
ingeniería de procesos de negocio e ingeniería de productos 
pueden ser encontradas en http: //www.pressman5.com 
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CAPÍTULO 


11 


CONCEPTOS Y PRINCIPIOS 
DEL ANÁLISIS 


A ingeniería de requisitos del software es un proceso de descubrimiento, refinamiento, 

modelado y especificación. Se refinan en detalle los requisitos del sistema y el papel 

asignado al software — inicialmenteasignado por el ingeniero del sistema —. Se crean 
modelos de los requisitos de datos, flujo de información y control, y del comportamiento ope- 
rativo. Se analizan soluciones alternativas y el modelo completo del análisis es creado. Donald 
Reifer [REI94] describe el proceso de ingeniería de requisitos del software en el siguiente 
párrafo: 


La ingeniería de requisitos es el uso sistemático de procedimientos, técnicas, lenguajes y herramientas para 
obtener con un coste reducido el análisis, documentación, evolución continua de las necesidades del usuario 
y la especificación del comportamiento externo de un sistema que satisfaga las necesidades del usuario. Tenga 
en cuenta que todas las disciplinas de la ingeniería son semejantes, la ingeniería de requisitos no se guía por 
conductas esporádicas, aleatorias o por modas pasajeras, si no que se debe basar en el uso sistemático de apro- 
ximaciones contrastadas. 


Tanto el desarrollador como el cliente tienen un papel activo en la ingeniería de requisitos 
del software —un conjunto de actividades que son denominadas análisis —. El cliente intenta 
replantear un sistema confuso, a nivel de descripción' de datos, funciones y comportamiento, 
en detalles concretos. El desarrollador actúa como un interrogador, como consultor, como pér- 


sona que resuelve problemas y como negociador. 


VISTAZO RÁPIDO 


Qué es? El papel global del software en 
un gran sistema es identificado duran- 
te la ingeniería del sistema (Capítulo 
10). De cualquier manera, es necesario 
"considerar una visión lo más profunda 
. posible del papel del software — para 
comprender los requisitos específicos 
que deben ser considerados en la 
“construcción de un software de alta 
calidad —.Este es el trabajo del análi- 
sis de requisitos del software. Para rea- 
++ lizar el trabajo adecuadamente, se 

* deben seguir un conjunto de conceptos 
y principios fundamentales. 


Quién lo hace? Generalmente, el inge- 
niero del software es quién realiza el 
análisis de requisitos. En cualquier 
caso, para aplicaciones de negocio 


complejas, un «analista de sistemas» 
—formadoen los aspectos del negocio 
del dominio de la aplicación — puede 
realizar esta tarea. 

¿Por qué es importante? Sino anali- 
zas, es muy probable que construyas 
una solución software muy elegante 
que resuelva incorrectamente el pro- 
blema. El resultado es tiempo y dinero 
perdido, frustración personal y clien- 
tes descontentos. 

¿Cuáles son los pasos? Los requisitos 
de datos, funciones y comportamiento 
son identificados por la obtención de 
información facilitada por el cliente. 
Los requisitos son refinados y analiza- 
dos para verificar su claridad, comple- 
titud y consistencia. La especificación 


se incorpora al modelo del software y 
es validada tanto por el ingeniero del 
software como por los clientes/usuarios. 


¿Cuál es el producto obtenido? Una 
representación efectiva del software 
debe ser producida como una conse- 
cuencia del análisis de requisitos. Tan- 
to los requisitos del sistema como los 
requisitos del software pueden ser 
representados utilizando un prototipo, 
una especificación o un modelo sim- 
bólico. 

¿Cómo puedo estar seguro de que 
lo he hecho correctamente? El 
resultado obtenido del análisis de 
requisitos del software debe ser revi- 
sado para conseguir: claridad, com- 
pletitud y consistencia. 


El análisis y la especificación de los requisitos puede parecer una tarea relativamente sen- 
cilla, pero las apariencias engañan. El contenido de comunicación es muy denso. Abundan 
las ocasiones para las malas interpretaciones O falta de información. Es muy probable que 
haya ambigiiedad. El dilema al que se enfrenta el ingeniero del software puede entenderse 
muy bien repitiendo la famosa frase de un cliente anónimo: «Sé que cree que entendió lo que 
piensa que dije, pero no estoy seguro de que se dé cuenta de que lo que escuchó no es lo que 
yo quise decir.» 


181 


www.elsolucionario.net 


INGENIERÍA DEL SOFTWARE. un eoruyur 1naurivu 


El análisis de los requisitos es una tarea de ingeniería 
del software que cubre el hueco entre la definición del 
software a nivel sistema y el diseño del software (Fig. 
11.1). El análisis de requisitos permite al ingeniero de 
sistemas especificar las característicasoperacionalesdel 
software (función, datos y rendimientos),indica la inter- 
faz del softwarecon otros elementos del sistema y esta- 
blece las restricciones que debe cumplir el software. 


. 
+. 


¡cho tiempo —lo mayor parte 
del proyecto— no implementondo 


> intentando decidir qué construir. 


El análisis de requisitos del software puede dividir- 
se en cinco áreas de esfuerzo: (1) reconocimiento del 
problema, (2) evaluación y síntesis, (3) modelado, (4) 
especificación y (5 )revisión. Inicialmente, el analista 
estudia la Especificación del Sistema (si existe alguna) 
y el Plan del Proyecto de Software. Es importante enten- 
der el software en el contexto de un sistema y revisar el 
ámbito del software que se empleó para generar las esti- 
maciones de la planificación. A continuación, se debe 
establecer la comunicación para el análisis de manera 
que nos garantice un correcto reconocimiento del pro- 
blema. El objetivo del analista es el reconocimiento de 
los elementos básicos del problema tal y como los per- 
cibe el cliente/usuario. 

La evaluación del problema y la síntesis de la solución 
es la siguiente área principal de esfuerzo en el análisis. El 
analista debe definir todos los objetos de datos observa- 
bles externamente, evaluar el flujo y contenidode la infor- 
mación, definir y elaborartodas las funciones del software, 
entender el comportamientodel software en el contexto 
de acontecimientos que afectan al sistema, establecer 
las características de la interfaz del sistema y descubrir 
restricciones adicionales del diseño. Cada una de estas 
tareas sirve para describirel problema de manera que se 
pueda sintetizar un enfoque o solución global. 

Por ejemplo, un mayorista de recambios de auto- 
móviles necesita un sistema de control de inventario. El 
analista averigua que los problemas del sistema manual 
que se emplea actualmenteson: (1) incapacidad de obte- 
ner rápidamente el estado de un componente; (2) dos o 
tres días de media para actualizar un archivo a base de 
tarjetas; (3) múltiples órdenes repetidas para el mismo 
vendedor debido a que no hay manera de asociar a los 
vendedores con los componentes, etc. Una vez que se 
han identificado los problemas, el analista determina 
qué información va a producir el nuevo sistema y qué 
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información se le proporcionará al sistema. Por ejem- 
plo, el cliente desea un informe diario que indique qué 
piezas se han tomado del inventario y cuántas piezas 
similares quedan. El cliente indica que los encargados 
del inventarioregistrarán el número de identificación de 
cada pieza cuando salga del inventario. 


Ingeniería - 
de sistemas 
de computadora 


Análisis 
de requisitos 
del software 


FIGURA 11.1. Análisis como puente entre la ingeniería 
y el diseño de software. 


Cons 


Cuento con hacer uno parte del diseño durante el análisis 
de requisitosy uno porte del análisis de requisitosdurante 
el diseño. 


Una vez evaluados los problemas actuales y la infor- 
mación deseada (entradas y salidas), el analista empie- 
za a sintetizar una o más soluciones. Para empezar, se 
definen en detalle los datos, las funciones de tratamiento 
y el comportamiento del sistema. Una vez que se ha 
establecido esta información, se consideran las arqui- 
tecturas básicas para la implementación. Un enfoque 
cliente/servidor parecería apropiada, pero ¿está dentro 
del ámbito esbozado en el Plan del Software? Parece 
que sería necesario un sistema de gestión de bases de 
datos, pero, ¿está justificada la necesidad de asociación 
del usuario/cliente? El proceso de evaluación y síntesis 
continúa hasta que ambos, el analista y el cliente, se 
sienten seguros de que se puede especificar adecuada- 
mente el software para posteriores fases de desarrollo. 

A lo largo de la evaluación y síntesis de la solución, 
el enfoque primario del analista está en el «qué» y no 
en el «cómo». ¿Qué datos produce y consume el siste. 
ma, qué funciones debe realizar el sistema, qué interfas 
ces se definen y qué restricciones son aplicables”. 


'Davis [DAV93] argumenta que los términos «que» y «cómo» son 
demasiado vagos Puede leer su libro sí desea encontrar un intere», 
sante debate sobre el tema Ñ 
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Durante la actividad de evaluación y síntesis de la 
solución, el analista crea modelos del sistema en un 
esfuerzo de entender mejor el flujo de datos y de control, 
el tratamiento funcional y el comportamiento operativo 
y el contenido de la información. El modelo sirve como 
fundamentopara el diseño del software y como base para 
la creación de una especificación del software. 


ES ¿Cuál será mi primer 
objetivo en esta etapa? 


.-—- ¿OS Y PRINCIPIOS DEL ANÁLISIS 


En el Capítulo 2, indicamos que puede no ser posi- 
ble una especificación detallada en esta etapa. El clien- 
te puede no estar seguro de lo que quiere. El 
desarrollador puede no estar seguro de que un enfoque 
específico consiga apropiadamente el funcionamiento 
y rendimiento adecuados. Por estas y otras muchas razo- 
nes, se puede llevar a cabo un enfoque alternativo del 
análisis de requisitos, denominado creación de prototi- 
pos oprototipado. El prototipado se comenta más tar- 
de en este capítulo. 


Antes que los requisitos puedan ser analizados, mode- 
lados o especificados, deben ser recogidos a través de 
fin proceso de obtención. Un cliente tiene un problema 
que pretende sea resuelto con una solución basada en 
tomputadora. Un desarrollador responde a la solicitud 
de ayuda del cliente. La comunicación ha empezado. 
Pero como ya hemos señalado, el camino de la comuni- 
cación al entendimiento está a menudo lleno de baches. 


11.2.1. Inicio del proceso 


Latécnica de obtención de requisitos más usada es lle- 
var a cabo una reunión o entrevista preliminar. La pri- 
masa reunión entre el ingeniero del software (el analista) 
y el cliente puede compararse con la primera cita entre 
dos adolescentes. Nadie sabe qué decir o preguntar; los 
dos están preocupados de que lo que digan sea malen- 
tendido; ambos piensan qué pasará (los dos pueden tener 
expectativasradicalmente diferentes): los dos están dese- 
ando que aquello termine, pero, al mismo tiempo, ambos 
desean que la cita sea un éxito. 


una pregunta es un tonto por cinco 
¿quién no lo hace es tonto para siempre. 


Sin embargo, hay que empezar la comunicación. 
Gause y Weinberg [GAU89] sugieren que el analista 
empiece preguntando cuestiones de contexto libre. Es 
Becir, un conjunto de preguntas que llevarán a un enten- 
dimiento básico del problema, qué solución busca, la 
fiaturaleza de la solución que se desea y la efectividad 
del primer encuentro. El primer conjunto de cuestiones 
dé contexto libre se enfoca sobre el cliente, los objeti- 
vos generales y los beneficios esperados. Por ejemplo, 
él analista podría preguntar: 

* ¿Quién está detrás de la solicitud de este trabajo? 

+ ¿Quién utilizará la solución? 

+ ¿Cuál será el beneficio económico del éxito de una 

solución? 

» ¿Hay alguna otra alternativa para la solución que 
necesita? 


Estas preguntas ayudan a identificar todos los parti- 
cipantes que tienen un interés en el software a construir. 
Además, las preguntas identifican los beneficios medi- 
bles en una implementación correcta de posibles alter- 
nativas para un desarrollo normal del software. 

El siguiente conjunto de preguntas permite al ana- 
lista obtener un mejor entendimiento del problema y al 
cliente comentar sus opiniones sobre la solución: 

+ ¿Cómo caracterizaría una «buena» salida (resultado) 
generada para una buena solución? 

* ¿Aqué tipo de problema(s) va dirigida esta solución? 

+ ¿Puede mostrarme (o describirme) el entorno en que 
se utilizará la solución? 

+. ¿Hay aspectos o restricciones especiales del rendi- 
miento que afecten a la manera de enfocar la solución? 


respuestas cloras evitan muchos 


El último conjunto de preguntas se concentra en la 
eficacia de la reunión. Gauge y Weinberg [GAU89] las 
denominan «meta-preguntas» y proponen la siguiente 
lista (abreviada): 

+ ¿Esusted la persona adecuada para responder a estas 
preguntas? ¿Sus respuestas son «oficiales»? 

» ¿Estoy preguntando demasiado? 

» ¿Hay alguien más que pueda proporcionar informa- 
ción adicional? 

+. ¿Hay algo más que debería preguntarle? 


Consiof 


Siunsistema o producto va 0 servir poro muchos usuarios, 
los requisitos deberán ser obtenidos de un grupo 
representativo de usuarios. Si sólo uno persona define 
lodos los requisitos, el riesgo de aceptación será olio. 


Estas preguntas (y otras) ayudarán a «romper el hie- 
lo» e iniciar la comunicación tan esencial para el éxito 
del análisis. Pero el formato de reunión tipo «pregunta 
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y respuesta» no es un enfoque que haya tenido mucho 
éxito. De hecho, esta sesión de preguntas y respuestas 
debería emplearse solamente en el primer encuentro y 
sustituirse después por una modalidad que combine ele- 
mentos de resolución del problema, negociación y espe- 
cificación. En la siguiente sección se presenta un enfoque 
a reuniones de este tipo. 


11.22, Técnicas para facilitar las especificacio- 
nes de una aplicación 


Los clientes y los ingenieros del software a menudo tie- 
nen una mentalidad inconsciente de «nosotros y ellos», 
En vez de trabajar como un equipo para identificar y refi- 
nar los requisitos, cada uno define por derecho su propio 
«territorio» y se comunica a través de una serie de memo- 
randos, papeles de posiciones formales, documentos y 
sesiones de preguntas y respuestas. La historia ha demos- 
trado que este método no funciona muy bien. Abundan 
los malentendidos, se omite información importante y 
nunca se establece una buena relación de trabajo. 


Una aproximación a FAST es llamada (Diseño común de 
aplicaciones» (JAD). Un detallado estudio de JAD puede 
encontrarseen 

www.bee.net /bluebird /jaddoc.htm 


Con estos problemas en mente es por lo que algunos 
investigadoresindependientes han desarrolladoun enfo- 
que orientado al equipo para la reunión de requisitos 
que se aplica durante las primeras fases del análisis y 
especificación. Denominadas Técnicas para facilitar 
las especificaciones de la aplicación (TFEA ), este enfo- 
que es partidario de la creación de un equipo conjunto 
de clientes y desarrolladores que trabajan juntos para 
identificarel problema, proponer soluciones, negociar 
diferentes enfoques y especificar un conjunto prelimi- 
nar de requisitos de la solución [ZAH90]. Hoy en día, 
las TFEA son empleadas de forma general por los sis- 
temas de información, pero la técnica ofrece un poten- 
cial de mejora en aplicaciones de todo tipo. 

Se han propuesto muchos enfoques diferentes de 
TFEA?. Cada uno utiliza un escenario ligeramente dife- 
rente, pero todos aplican alguna variación en las siguien- 
tes directrices básicas: 
la reunión se celebra en un lugar neutral y acuden 
tanto los clientes como los desarrolladores. 
se establecen normas de preparación y de partici- 
pación. 
se sugiere una agenda lo suficientemente formal 
como para cubrir todos los puntos importantes, pero 


2 Dos de los enfoques más populares de TFEA son Desarrollo Con- 
junto de Aplicaciones (JAD), desarrollado por IBM, y The METHOD, 
desarrollado por Performance Resources, Inc., Falls Church, VA. 
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lo suficientemente informal como para animar el libre 
flujo de ideas. 


un «coordinador» (que puede ser un cliente, un desa- 
rrollador o un tercero) que controle la reunión. 

se usa un «mecanismo de definición» (que puede ser 
hojas de trabajo, gráficos, carteles o pizarras). 

el objetivo es identificar el problema, proponer ele- 
mentos de solución, negociar diferentes enfoques y 
especificar un conjunto preliminar de requisitos de 
la solución en una atmósfera que permita alcanzarel 
objetivo. 


¿Qué diferencias existen 
entre una reunión TFEA 
y una reunión ordinaria? 


Para comprender mejor el flujo de acontecimientos 
tal y como ocurren en una reunión TFEA, presentamos 
un pequeño escenario que esboza la secuencia de acon- 
tecimientos que llevan a la reunión, los que ocurren en 
la reunión y los que la siguen. 


En las reuniones iniciales entre el desarrollador y el 
cliente (Sección 11.2.1) se dan preguntas y respuestas 
básicas que ayudan a establecer el ámbito del problema 
y la percepción global de una solución. Fuera de estas 
reuniones iniciales, el cliente y el desarrollador escri- 
ben una «solicitud de producto» de una o dos páginas. 
Se selecciona lugar, fecha y hora de reunión TFEA y se 
elige un coordinador. Se invita a participar a represen- 
tantes de ambas organizaciones; la del cliente y la de 
desarrollo. Se distribuye la solicitud de producto a los 
asistentes antes de la fecha de reunión. 


5) 
e 


CLAVE 


Antes de una reunión FAST confecciona una lista de 
objetos, servicios, restriccionesy criterios de rendimiento 


Mientras se revisa la solicitud días antes de la reu- 
nión, se pide a todos los asistentes que hagan una lista 
de objetos que formen parte del entorno del sistema, 
otros objetos que debe producir el sistema y objetos que 
usa el sistema para desarrollar sus funciones. Además, 
se pide atodos los asistentes que hagan otra lista de ser- 
vicios (procesos o funciones) que manipulan o interac- 
túan con los objetos. Finalmente, se desarrollan también 
listas de restricciones (por ejemplo, costes, tamaño, 
peso) y criterios de rendimiento (por ejemplo, veloci- 
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dad, precisión). Se informa a los asistentes que no se 
espera que las listas sean exhaustivas, pero que sí que 
reflejen su punto de vista del sistema. 

Por ejemplo”, imagínese que a un equipo de trabajo 
TFEA de una compañía de productos para el consumi- 
dor se le ha dado la siguiente descripción del producto: 

Nuestras investigaciones indican que el mercado de siste- 
mas de seguridad para el hogar está creciendo a un ritmo del 
40 por 100 anual. Nos gustaría entrar en este mercado cons- 
truyendo un sistema de seguridad para el hogar basado en un 
microprocesadorque proteja y/o reconozca varias situaciones 
indeseables tales como irrupciones ilegales, fuego, inundacio- 
nes y otras. El producto, provisionalmente llamado HogarSe- 
guro, utilizará los sensores adecuados para detectar cada 
situación, puede programarsepor el propietario del hogar y lla- 
mará automáticamente a una agencia de vigilancia cuando se 
detecte alguna de estas situaciones. 


En realidad, se proporcionatía considerablemente más 
información en esta fase. Pero incluso con información 
adicional, habría ambigiedades presentes, existirán omi- 
siones probablemente y podrían ocurrirerrores. Por aho- 
ra, la «descripción de producto» anterior bastará. 

El equipo TFEA está compuesto por representantes de 
marketing, ingeniería del software y del hardware, y de la 
fabricación también participará un coordinador externo. 


E 
LAVE 


los objetos deben ser manipulados por servicios y deben 
«contemplar» las restriccionesy rendimientos definidos 
por el equipo FAST. 


Todos los componentes del equipo TFEA desarrollan 
las listas descritas anteriormente. Los objetos descritos 
para HogarSeguro podrían incluir detectores de humo, 
sensores de ventanas y puertas, detectores de movimien- 
tos, una alarma, un acontecimiento (se ha activado un 
sensor), un panel de control, una pantalla, números 
de teléfono, una llamada de teléfono, etc. La lista de 
servicios podría incluir la instalación de la alarma, vigi- 
lancia de los sensores, marcado de teléfono, programa- 
ción del panel de control y lectura de la pantalla (fíjese 
que los servicios actúan sobre los objetos). De igual 
manera, todos los asistentes TFEA desarrollarán una lis- 
ta de restricciones (por ejemplo, el sistema debe tener 
un coste de fabricación de menos de £80, debe tener 
una «interfaz amigable» con el usuario y debe conectar 
directamentecon una línea telefónica estándar) y de cri- 
terios de rendimiento (por ejemplo, un acontecimiento 
detectado por un sensor debe reconocerse en un segun- 
do; se debería implementar un esquema de prioridad de 
acontecimientos). 

Cuando empieza la reunión TFEA, el primer tema 
de estudio es la necesidad y justificación del nuevo 


3 Ese ejemplo (con extensiones y variaciones)se empleará para ilus- 
trar métodos importantes de ingeniería del software en muchos de 
los capítulos siguientes. Como ejercicio, sería útil que realizara su 
propia reunión TFEA y desarrollara un conjunto de listas. 
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producto, pues todo el mundo debería estar de acuer- 
do en que el desarrollo (o adquisición) del producto 
está justificada. Una vez que se ha conseguido el acuer- 
do, cada participante presenta sus listas para su estu- 
dio. Las listas pueden exponerse en las paredes de la 
habitación usando largas hojas de papel, pinchadas o 
pegadas, o escritas en una pizarra. Idealmente debería 
poderse manejar separadamente cada entrada de las 
listas para poder combinarlas, borrarlas o añadir otras. 
En esta fase, está estrictamente prohibido el debate o 
las críticas. 


MON 


Evita el impulso de cortar la idea de un cliente 

por ((demasiadocostosa» o «poco práctica». 

lo ideo es negociar alga que sea aceptable paro todos. 
Es decir, debes tener uno mente abierto. 


Una vez que se han presentado las listas individua- 
les sobre un tema, el grupo crea una lista combinada. 
La lista combinada elimina las entradas redundantes y 
añade las ideas nuevas que se les ocurran durante la pre- 
sentación, pero no se elimina nada más. Cuando se han 
creado las listas combinadas de todos los temas, sigue 
el estudio — moderadopor el coordinador—. La lista 
combinada es ordenada, ampliada o redactada de nue- 
vo para reflejar apropiadamente el producto o sistema 
que se va a desarrollar. El objetivo es desarrollar una 
lista de consenso por cada tema (objetos, servicios, res- 
tricciones y rendimiento). Después estas listas se ponen 
aparte para utilizarlas posteriormente. 

Una vez que se han completado las listas de con- 
senso, el equipo se divide en subequipos; cada uno tra- 
baja para desarrollar una mini-especificación de una o 
más entradas de cada lista*. La mini-especificación es 
una elaboración de la palabra o frase contenida en una 
lista. Por ejemplo, la mini-especificación del objeto 
panel de control de HogarSeguro podría ser: montado 
en la pared; tamaño aproximado 23 — 13 centímetros; 
contiene el teclado estándar de 12 teclas y teclas espe- 
ciales; contiene una pantalla LCD de la forma mostra- 
da en el bosquejo (no presentado aquí); toda la 
interacción del cliente se hace a través de las teclas usa- 
das para activar o desactivar el sistema; software para 
proporcionar una directriz de empleo, recordatorios, 
etc., conectado a todos los sensores. 

Cada subequipo presenta entonces sus mini-especi- 
ficaciones a todos los asistentes TFEA para estudiarlas. 
Se realizan nuevos añadidos, eliminaciones y se sigue 
elaborando. En algunos casos, el desarrollo de algunas 
mini-especificaciones descubrirá nuevos objetos, ser- 
vicios, restricciones o requisitos de rendimiento que se 
añadirán a las listas originales. Durante todos los estu- 


4 Una alternativa puede ser la creación de casos de uso. Ver Sección 
11.2.4para más detalles. 
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dios, el equipo sacará a relucir aspectos que no podrán 
resolverse durante la reunión. Se hará una lista de estas 
ideas para tratarlas más adelante. 


lo porte más importante del trabajo. 


Una vez que se han completado las mini-especifica- 
ciones, cada asistente de la TFEA hace una lista de crite- 
rios de validación del producto/sistema y presenta su lista 
al equipo. Se crea así una lista de consenso de criterios de 
validación. Finalmente, uno o más participantes (o algún 
tercero) es asignado para escribir el borrador entero de 
especificación con todo lo expuesto en la reunión TFEA. 

TFEA no es la panacea para los problemas que se 
encuentran en las primeras reuniones de requisitos, pero 
el enfoquede equipo proporciona las ventajas de muchos 
puntos de vista, estudio y refinamiento instantáneo y un 
paso adelante hacia el desarrollo de una especificación. 


11.2.3. Despliegue de la función de calidad 


El despliegue de lafunción calidad (DFC)es una téc- 
nica de gestión de calidad que traduce las necesidades 
del cliente en requisitos técnicos del software. Origi- 
nalmente desarrolladoen Japón y usado por primera vez 
en Kobe Shipyard of Mitsubishi Heavy Industries, Ltd. 
A primeros de los años 70, DFC «se concentra en maxi- 
mizar la satisfacción del cliente» [ZUL92]. Para con- 
seguirlo, DFC hace énfasis en entender lo que resulta 
valioso para el cliente y después desplegar estos valo- 
res alo largo del proceso de ingeniería. DFC identifica 
tres tipos de requisitos [ZUL92]: 


7 VE 


DFC define los requisitos orientados a maximizar 
lo satisfacción del cliente. 


Requisitos normales. Se declaran objetivos y metas para un 
producto o sistema durante las reunionescon el cliente. Siestos 
requisitosestán presentes, el cliente quedará satisfecho. Ejem- 
plos de requisitos normales podrían ser peticiones de tipos de 
presentación gráfica, funciones específicas del sistema y nive- 
les definidos de rendimiento. 


Requisitos esperados. Estos requisitos son implícitos al 
producto o sistema y pueden ser tan fundamentales que el 
cliente no los declara explícitamente. Su ausencia sería moti- 
vo de una insatisfacción significativa. Ejemplos de requisi- 
tos esperados son: facilidad de interacción hombre-máquina, 
buen funcionamiento y fiabilidad general, y facilidad de ins- 
talación del software. 


Requisitos innovadores.Estas características van más allá 
de las expectativas del cliente y suelen ser muy satisfactorias. 
Por ejemplo, se pide un software procesador de textos con las 
características estándar. El producto entregado contiene cier- 
tas capacidades de diseño de página que resultan muy válidas 
y que no eran esperadas. 
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Con 


Todos queremos implementar muchos requisitos 
apasionantes, pero debemos ser cuidadosos. Podemos 
concretar «requisitos inútiles», o conducira requisitos 
innovadores que conducena un producto demasiado 
futurista. 


En realidad, el DFC se extiende a todo el proceso de 
ingeniería [AKA90]. Sin embargo, muchos conceptos 
DFC son aplicables al problema de la comunicación con 
el cliente a que se enfrenta un ingeniero del software duran- 
te las primeras fases del análisis de requisitos. Presenta- 
mos una visión general sólo de estos conceptos (adaptados 
al software de computadora)en los párrafos siguientes. 

En las reuniones con el cliente el despliegue defun- 
ción se emplea para determinar el valor de cada fun- 
ción requerida para el sistema. El despliegue de 
información identifica tanto los objetos de datos como 
los acontecimientos que el sistema debe producir y 
consumir. Estos están unidos a las funciones. Final- 
mente, el despliegue de tareas examina el comporta- 
miento del sistema o producto dentro del contexto de 
su entorno. El análisis de valor es llevado a cabo para 
determinar la prioridad relativa de requisitos determi- 
nada durante cada uno de los tres despliegues men- 
cionados anteriormente. 


Referencia Web 


B Instituto DFC es una excelentefuente de información: 
www.qfdi.org 


El DFC utiliza observacionesy entrevistascon el clien- 
te, emplea encuestasy examina datos históricos (por ejem- 
plo, informes de problemas) como datos de base para la 
actividad de recogida de requisitos. Estos datos se tradu- 
cen después en una tabla de requisitos —-denominada tabla 
de opinión del cliente — que se revisa con el cliente. Enton- 
ces se usa una variedad de diagramas, matrices y méto- 
dos de evaluación para extraerlos requisitos esperadose 
intentar obtenerrequisitos innovadores [BOS91]. 


11.2.4. Casos d e uso 


Una vez recopilados los requisitos, bien por reunio- 
nes informales, TFEA o DFC, el ingeniero del software 
(analista) puede crear un conjunto de escenarios que 
identifiquen una línea de utilización para el sistemaque 
va a ser construido. Los escenarios, algunas veces lla- 
mados casos de uso [JAC92], facilitan una descripción 
de cómo el sistema se usará. 


Y) 
EA 
Un caso de uso es un escenario que describe cómo 
el softwore va a ser usado en uno determinadasituación. 
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Para crear un caso de uso, el analista debe primero 
identificar los diferentes tipos de personas (o dispositi- 
vos) que utiliza el sistema o producto. Estos actores 
actualmente representan papeles que la gente (o dispo- 
sitivos) juegan como impulsores del sistema. Definido 
más formalmente, un actor es algo que comunica con 
el sistema o producto y que es externo al sistema en sí 
mismo. 

Es importante indicar que un actor y un usuario no 
son la misma cosa. Un usuario normal puede jugar un 
número de papeles diferentes cuando utiliza un sistema, 
por lo tanto un actor representa una clase de entidades 
externas (a veces, pero no siempre personas) que lleva 
acabo un papel. Como ejemplo, considerar un operador 
de una máquina (un usuario) que interactúa con el orde- 
nador central para un elemento de fabricación que con- 
tiene un número de robots y máquinas bajo control 
numérico. Después de una revisión cuidadosa de los 
requisitos, el software del computador central requiere 
cuatro modelos diferentes (papeles) de interacción: modo 
programación, modo prueba, modo monitorización y 
modo investigación. Además, se pueden definir cuatro 
actores: programador, probador, supervisor e investiga- 
dor. En algunos casos, el operador de la máquina puede 
realizar todos los papeles. En otras ocasiones, diferen- 
tes personas pueden jugar el papel de cada actor. 


Casos de uso 


DOCUMENTO 


Porque la obtención de requisitos es una actividad 
de evolución, no todos los actores se identifican duran- 
te la primera iteración. Es posible identificar actores ini- 
ciales [JAC93] durante la primera iteración y actores 
secundarios cuando más se aprende del sistema. Los 
actores iniciales interactúan para conseguir funciones 
del sistema y derivar el beneficio deseado del sistema. 
Ellos trabaian directa y frecuentemente con el software. 
Los actores secundarios existen para dar soporte al sis- 
tema que los actores iniciales han dado forma con su 
trabajo. 

Una vez que se han identificado los actores, se pue- 
den desarrollar los casos de uso. El caso de uso descri- 
be la manera en que los actores interactúan con el 
sistema. Jacobson [JAC93] sugiere un número de pre- 
guntas que deberán responderse por el caso de uso: 

+ ¿Cuáles son las principales tareas o funciones que 
serán realizadas por el actor? 

+ ¿Cuál es el sistema de información que el actor 
adquiere, produce o cambia? 

* ¿Qué actor informará al sistema de los cambios en 
el entorno externo? 


+ ¿Qué información necesita el actor sobre el sistema? 
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5 
AS 


CLAVE 


tos cosos de usos están definidos desde el punto de vista 
de un actor. Un actor es un papel que las personas 
(usuarios) o dispositivos juegan cuando interaccionon 
con el software. 


En general, un caso de uso es, simplemente, un tex- 
to escrito que describe el papel de un actor que interac- 
túa con el acontecer del sistema. 

Volviendo a los requisitos básicos de HogarSeguro 
(Sección 11.2.2), podemos identificar tres actores: el 
propietario (el usuario), sensores (dispositivos vincula- 
dos al sistema), y el subsistema de monitorización y res- 
puesta (la estación central que monitoriza HogarSeguro). 
Para los propósitos de este ejemplo, consideremos úni- 
camente al actor propietario. El propietario interactúa 
con el producto en un número de diferentes caminos: 

. introduce una contraseña para permitir cualquier 
interacción 

+ pregunta acerca del estado de una zona de seguridad 

+ pregunta acerca del estado de un sensor 

+ presiona el botón de alarma en caso de emergencia 


+ activa/desactiva el sistema de seguridad 


Una discusión detallada de los casos de usos, incluyendo 
ejemplos, referencias y plontillos, se presenta en 
members.ooLcom/acodcburn/popers/OnUseCases.htm 


Un caso de uso para el sistema de activación persigue: 


1. El propietario observa un prototipo del panel de con- 
trol de FHogarSeguro (Fig. 11.2) para determinar si 
el sistema está preparado para la entrada. Si el sts- 
tema no está preparado, el propietario debe física- 
mente cerrar ventanas/puertas para que se encienda 
el indicador de preparado. (El indicador no prepa- 
rado implica que el sensor está abierto, por ejemplo, 
que la puerta O ventana está abierta.) 


away () 


stay max ': test bypass 
M5 AONOXO 


instant '.code chime 


MC E 


ready 


ap 


FIGURA 11.2. Panel de control de Hogar Seguro. 


HOGARSEGURO 


bypass 
not ready 


: armed power 


Indicadores 
en inglés. 


2. El propietario utiliza el teclado para introducir una 
contraseña de cuatro dígitos. La contraseña es com- 
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parada con la contraseña válida almacenadaen el sis- 
tema. Si la contraseña es errónea, el panel de control 
emitirá un sonido y se restaurará para incorporar una 
nueva entrada. 


2 


El propietario selecciona y pulsa stay o away (ver 
Fig. 11.2) para activar el sistema. Stay activa sola- 
mente sensores perimetrales (cuando detectan movi- 
miento interno se desactivan). Away activa todos los 
sensores. 


Cuando ocurre una activación, una luz de alarma 
puede ser observada por el propietario. 


Cada caso de uso facilita un escenario sin ambi- 
giedad en la interacción entre el actor y el software. 
Esto puede usarse para especificar requisitos de tiem- 
po u otras restricciones del escenario. Por ejemplo, en 
el caso de uso referido anteriormente, los requisitos 


Durante las dos pasadas décadas, se han desarrollado 
un gran número de métodos de modelado. Los inves- 
tigadores han identificado los problemas del análisis y 
sus causas y han desarrollado varias notaciones de 
modelado y sus correspondientes conjuntos de heurís- 
ticas para solucionarlos. Cada método de análisis tie- 
ne su punto de vista. Sin embargo, todos los métodos 
de análisis se relacionan por un conjunto de principios 
operativos: 


1, Deberepresentarse y entenderse el dominio de infor- 
mación de un problema. 


2. Deben definirse las funciones que debe realizar el 


software. 


Debe representarse el comportamiento del software 
(como consecuencia de acontecimientos externos). 


Deben dividirse los modelos que representan infor- 
mación, función y comportamiento de manera que 
se descubran los detalles por capas (ojerárquica- 
mente). 


. El proceso de análisis debería ir desde la informa- 
ción esencial hasta el detalle de la implementación. 
¿Cuáles son los principios 


? subyacentes que guían el 
trabajo de análisis? 


Aplicando estos principios, el analista se aproxima 
al problema sistemáticamente. Se examina el dominio 
de información de manera que pueda entenderse com- 
pletamente la función. Se emplean modelos para poder 
comunicar de forma compacta las características de la 
función y su comportamiento. Se aplica la partición para 


$ Lo ideal es que la evaluación sea realizada por funciones indi- 
viduales de,la organización o negocio representadas por un actor. 
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indican que ocurrirá 30 segundos después de pulsar la 
tecla stay o away. Esta información puede añadirse al 
caso de uso. 

Los casos de uso describen escenarios que serán per- 
cibidos de distinta forma por distintos actores. Wyder 
[WYD96] indica que la calidad de la función desplegada 
puede ser usada para desarrollarun amplio valor de prio- 
ridades para cada caso de uso. Para acabar, los casos de 
uso son evaluados desde el punto de vista de todos los 
actores definidos para el sistema. Se asigna un valor de 
prioridad a cada caso de uso (por ejemplo, un valor de 1 
a 10)para cada acto?. Se calcula una prioridad, indican- 
do la importancia percibida de cada caso de uso. 

Cuando un modelo de proceso iterativo es usado por 
la ingeniería del software orientado a objetos, las prio- 
ridades pueden influiren qué funcionalidad del sistema 
será entregada primero. 


O 


reducir la complejidad. Son necesarias las visiones esen- 
ciales y de implementación del software para acomo- 
dar las restricciones lógicas impuestas por los requisitos 
del procesamiento y las restricciones físicas impuestas 
por otros elementos del sistema. 

Además de los principios operativos de análisis men- 
cionados anteriormente, Davis [DAV95a] sugiere un 
conjunto” de principios directrices para la «ingeniería 
de requisitos»: 

Entender el problema antes de empezar a crear el 
modelo de análisis. Hay tendencia a precipitarse en 
busca de una solución, incluso antes de entender el 
problema. ¡Esto lleva a menudo a un elegante soft- 
ware para el problema equivocado! 

Desarrollar prototipos que permitan al usuario 
entender cómo será la interacción hombre-máquina. 
Como el concepto de calidad del software se basa a 
menudo en la opinión sobre la «amigabilidad» de la 
interfaz, el desarrollo de prototipos (y la iteración 
que se produce) es altamente recomendable. 


Registrar el origen y la razón de cada requisito. Este 


es el primer paso para establecer un seguimiento 
hasta el cliente. 


Usarmúltiplesplanteamientos de requisitos. La cons- 
trucción de modelos de datos, funcionales y de com- 
portamiento, le proporcionan al ingeniero del 
software tres puntos de vista diferentes. Esto reduce 
la probabilidad de que se olvide algo y aumenta la 
probabilidad de reconocer la falta de consistencia. 

Dar prioridad a los requisitos. Las fechas ajustadas 
de entrega pueden impedir la implementación de 


$ Aquí se menciona sólo un pequeño subconjunto de los principios 
de ingeniería de requisitos de Davis. Para obtener más información, 
véase [DAV95a]. 
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todos los requisitos del software. Si se aplica un 
modelo de proceso incremental (Capítulo 2), se deben 
identificar los requisitos que se van a entregar en la 
primera entrega. 


= Trabajar-para eliminar la ambigiúiedad. Como la 
mayoría de los requisitos están descritos en un len- 
guaje natural, abunda la oportunidad de ambigijeda- 
des. El empleo de revisiones técnicas formales es 
una manera de descubrir y eliminar la ambigitedad. 


dor haré lo que le digos, pero ello puede 
diferente de lo que tengas. en mente. 
Weizenbaum ' 


Un ingeniero del software que se aprenda estos prin- 
cipios de memoria es muy probable que desarrolle una 
especificación del software que proporcione un exce- 
lente fundamento para el diseño. 


11.3.1. El dominio de la información 


Todas las aplicaciones software pueden denominarse 
colectivamenteprocesamiento de datos. Es interesan- 
te que este término contenga una clave para nuestro 
entendimiento de los requisitos del software. El soft- 
ware se construye para procesar datos, para transfor- 
mar datos de una forma a otra, es decir, para aceptar 
una entrada de información, manipularla de alguna 
manera y producir una salida de información. Esta 
declaración fundamental de objetivos es cierta, tanto 
si construimos software por lotes para un sistema de 
nóminas, como si construimos software dedicado de 
tiempo real para controlar el flujo de combustible de 
un motor de automóvil. 


O 
CLAVE 

E dominio de información de un problema agrupan 

elementos de datos u objetos que contienen números, 


texto, imágenes audio, video o cualquier combinación 
de ellos. 


Es importante recalcar, sin embargo, que el softwa- 
re también procesa sucesos. Un suceso representa algún 
aspecto de control del sistema.y no es más que un dato 
binario (es encendido o apagado, verdadero o falso, está 
allío no). Por ejemplo, un sensor de presión detecta la 
presión que excede de un valor seguro y envía una señal 
de alarma al software de vigilancia. La señal de alarma 
es un suceso que controla el comportamiento del siste- 
ma. Por tanto, los datos (números, caracteres, imáge- 
nes, sonidos, etc.) y el control (acontecimientos)residen 
dentro del dominio de la información de un problema. 

El primer principio operativo de análisis requiere el 
examen del dominio de la información y la creación de 
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un modelo de datos. Este dominio contiene tres visio- 
nes diferentes de los datos y del control a medida que 
se procesa cada uno en un programa de computadora: 
(1) contenido de la información y relaciones, (2) flujo 
de la información y (3) estructura de la información. 
Para entender completamente el dominio de la infor- 
mación, debería estudiarse cada una de estas visiones. 


Cons) 


Para comenzar a comprender el dominio de información, 
la primera pregunto que debe ser realizada es: 
«¿Qué información de salida generará el sistema?» 


El contenido de la información representa los obje- 
tos individuales de datos y de control que componen 
alguna colección mayor de información a la que trans- 
forma el software. Por ejemplo, el objeto datos cheque 
es una composición de varios componentes de infor- 
mación importantes: el nombre del beneficiario, la can- 
tidad neta a pagar, el importe bruto, deducciones, etc. 
Por tanto, el contenido de cheque es definido por los 
atributos necesarios para crearlo. De forma similar, el 
contenido de un objeto de control denominado estado 
del sistema podría definirse mediante una cadena de 
bits. Cada bit representa un elemento diferente de infor- 
mación que indica si un dispositivo en particular está 
en línea O fuera de línea. 

Los objetos de datos y de control pueden relacio- 
narse con otros objetos de datos o de control. Por ejem- 
plo, el objeto de datos cheque tiene una o más relaciones 
con los objetos empleado, banco y otros. Durante el aná- 
lisis del dominio de la información, se deberían definir 
estas relaciones. 

El flujo de la información representa cómo cambian 
los datos y el control a medida que se mueven dentro 
de un sistema. Como se muestra en la Figura 11.3, los 
objetos de entrada se transforman para intercambiar 
información (datos y/o control), hasta que se transfor- 
man en información de salida. A lo largo de este cami- 
no de transformación (o caminos), se puede introducir 
información adicional de un almacén de datos (por ejem- 
plo, un archivoen disco o memoria intermedia). Las trans- 
formaciones que se aplican a los datos son funciones o 
subfuncionesque debe realizar un programa. Los datos y 
control que se mueven entre dos transformaciones (fun- 
ciones) definen la interfaz de cada función. 

La estructura de la información representa la orga- 
nización interna de los elementos de datos o de con- 
trol. ¿Hay que organizar los elementos de datos o de 
control como una tabla de dimensión n o como una 
estructura jerárquica en árbol? Dentro del contexto de 
la estructura, ¿qué información está relacionada con 
otra información? ¿Está contenida toda la información 
en una sola estructura o se van a utilizar varias? ¿Cómo 
se relaciona la información de una estructura con la de 
otra? Estas y otras preguntas se responden mediante 
una valoración de la estructura de la información. 
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Debería resaltase que la estructura de datos, un con- 
cepto afín que se estudiará más adelante en este libro, 
se refiere al diseño e implementación de la estructura 
de la información. 


11.3.2. Modelado 


Los modelos se crean para entender mejor la entidad que 
se va a construir. Cuando la entidad es algo físico (un edi- 
ficio, un avión, una máquina), podemos construir un 
modelo idéntico en forma, pero más pequeño. Sin embar- 
go, cuando la entidad que se va a construir es software, 
nuestro modelo debe tomar una forma diferente. Debe 
ser capaz de modelar la información que transforma el 
software, las funciones (y subfunciones) que permiten 
que ocurran las transformaciones y el comportamiento 
del sistema cuando ocurren estas transformaciones. 

El segundo y tercer principios operativos del análi- 
sis requieren la construcción de modelos de función y 
comportamiento. 


¿ Qué tipos de modelos 
debemos crear durante 
el análisis de requisitos? 


Modelos funcionales. El software transforma la infor- 
mación y, para hacerlo, debe realizar al menos tres funcio- 
nes genéricas: entrada, procevamiento y salida. Cuando se 
crean modelos funcionales de una aplicación, el ingeniero 
del software se concentra en funciones específicas del pro- 
blema. El modelo funcional empieza con un sencillo mode- 
lo a nivel de contexto (por ejemplo, el nombre del software 
que se va a construir). Después de una serie de iteraciones, 
se consiguen más y más detalles funcionales, hasta que se 
consigue representar una minuciosa definición de toda la fun- 
cionalidad del sistema. 


Objetols) po Objeto(s) 
da Ms de salida 

SE Transformación Y Mermedios 

—_—>» a ca _—»> 


Almacén 
de datos/control 


FIGURA 11.3. Flujo y transformación de la información. 


Modelos de comportamiento. La mayoría del software 
responde a los acontecimientos del mundo exterior. Esta 
característica estímulo-respuesta forma la base del modelo 
del comportamiento. Un programa de computadora siempre 
está en un estado, un modo de comportamiento observable 
exteriormente (por ejemplo, esperando, calculando, impri- 
miendo, haciendo cola) que cambia sólo cuando ocurre algún 
suceso. Por ejemplo, el software permanecerá en el estado 
de espera hasta que (1) un reloj interno le indique que ha 
pasado cierto intervalo de tiempo, (2) un suceso externo (por 
ejemplo, un movimiento del ratón) provoca una interrupción, 
o (3) un sistema externo señala al software que actúe de algu- 


na manera. Un modelo de comportamiento crea una repre- 
sentación de los estados del software y los sucesos que cau- 
san que cambie de estado. 


Los modelos creados durante el análisis de requisi- 
tos desempeñan unos papeles muy importantes: 


+» El modelo ayuda al analista a entender la informa- 
ción, la función y el comportamiento del sistema, 
haciendo por tanto más fácil y sistemática la tarea de 
análisis de requisitos. 


+ El modelo se convierte en el punto de mira para la 
revisión y por tanto la clave para determinar si se ha 
completado, su consistencia y la precisión de la espe- 
cificación. 

+. El modelo se convierte en el fundamento para el 
diseño, proporcionando al diseñador una represen- 
tación esencial del software que pueda trasladarse al 
contexto de la implementación. 


¿ Cómo usar los modelos 
creados durante el trabajo 
de análisis de requisitos? 


Los métodos de análisis estudiados en los Capítulos 

12 y 21 son de hecho métodos de modelado. Aunque el 

método de modelado empleado es a menudo cuestión 

de preferencias personales (o de la organización), la acti- 

vidad de modelado es fundamental para un buen traba- 
jo de análisis. 


11.33. Partición 


A menudo los problemas son demasiado grandes o com- 
plejos para entenderlos globalmente. Por este motivo, 
tendemos a hacer una partición (dividir) de estos pro- 
blemas en partes que puedan entenderse fácilmente y 
establecer las interacciones entre las partes de manera 
que se pueda conseguirla función global. El cuarto prin- 
cipio operativo del análisis sugiere que se pueden par- 
tir los dominios de la información, funcional y de 
comportamiento. 


OS 
Y 
La descomposición es un proceso que resulta 


de la elaboraciónde datos, funciones o comportamientos. 
Puede ser realizada horizontal o verticalmente, 


En esencia, lapartición descompone un problema en 
sus partes constitutivas. Conceptualmente, establecemos 
una representación jerárquica de la información o de la 
función y después partimos el elemento de orden supe- 
rior (1) exponiendo más detalles cada vez al movernos 
verticalmente en la jerarquía o (2) descomponiendo el 
problema si nos movemos horizontalmente en la jerar- 
quía. Para ilustrar estos enfoques de partición, reconsi- 
deremos el sistema de seguridad HogarSeguro descrito 
en la Sección 11.2.2. La asignación de software para 
HogarSeguro (obtenido como consecuencia de las acti- 
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vidades de ingeniería del sistema y de las reuniones 
TFEA) puede establecerse en los párrafos siguientes: 


El software de HogarSeguro permite al propietario con- 
figurar el sistema de seguridad cuando se instala, vigila todos 
los sensores conectados al sistema de seguridad e interactúa 
con el propietario a través de un teclado y teclas funciona- 
les del panel de control de HogarSeguro mostrado en la Figu- 
ra 11.2. 


Durante la instalación, el panel de control de HogarSegu- 
ro se emplea para «programar» y configurarel sistema. A cada 
sensor se le asigna un número y un tipo, se programa una con- 
traseña para activar y desactivar el sistema y se introducen el 
(los) número(s) de teléfono que se marcará(n) cuando un sen- 
sor detecte un suceso que haga saltar la alarma. 


Cuando un sensor detecta un acontecimiento, el software 
invoca una alarma sonora asociada al sistema. Después de un 
retardo especificado por el propietario durante la configuración 
del sistema, el software marca un número de teléfono de una 
empresa de seguridad y proporciona información sobre la direc- 
ción, informando de la naturaleza del acontecimiento detecta- 
do. El número se volverá a marcar cada 20 segundos hasta que 
se obtenga la conexión telefónica. 


Toda la interacción con Hogarseguro es manejada por un 
subsistema de interacción con el usuario que lee la entrada de 
información proporcionada a través del teclado y las teclas fun- 
cionales, las pantallas que presentan mensajes y el estado del 
sistemaen la pantalla LCD. La interacción con el teclado toma 
la siguiente forma... 


Los requisitos del software de HogarSeguro pueden 
analizarse partiendo los dominios de información, fun- 
cional y de comportamiento del producto. Para ilus- 
trarlo, partiremos el dominio funcional del problema. 
La Figura 11.4 ilustra una descomposición horizontal 
del software HogarSeguro. El problema se parte median- 
te la representación de las funciones constitutivas del 
software HogarSeguro, moviéndose horizontalmenteen 
lajerarquía funcional. En el primer nivel de la jerarquía 
aparecen tres funciones principales. 


: emprender no puede ser sustituido 
tuno octividod intenso. 
Willioms 


Las subfunciones asociadas con una función principal 
de HogarSeguro pueden examinarse mediante la exposi- 
ción vertical detallada en lajerarquía, tal y como se ilus- 
traen la Figura 11.5. Moviéndose hacia abajo a lo largo 
de un camino, por ejemplo la función sensores de vigi- 
lancia, la partición se hace vertical para mostrar mayores 
niveles de detalle funcional. El enfoque de partición que 
hemos aplicado a las funciones de HogarSeguro puede 
aplicarse también al dominio de la información y al de 
comportamiento. De hecho, la partición del flujo de la 
información y del comportamiento del sistema (tratados 
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arras 


en el Capitulo 12) proporcionará una visión más profun- 
da de los requisitos del sistema. A medida que se parte el 
sistema, se obtienen las interfaces entre las funciones. Los 
datos y elementos de control que se mueven a través de 
una interfaz deberían restringirse a las entradas necesa- 
rias para realizar la función en cuestión y a las salidas 
requeridas por otras funciones o elementos del sistema. 


Sotfware de Hogarseguro 


A a 


Configurar Monitorizar Interactuar 
sistema sensores con el usuario 


Partición horizontal > seems coronas 


FIGURA 11.4. Partición horizontal de unía función 
de Hogar Seguro. 


11.34. Visiones esenciales y deimplementación' 


Una visión esencial de los requisitos del software presenta 
las funciones a conseguir y la información a procesar sin 
tener en cuenta los detalles de la implementación. Por 
ejemplo, la visión esencial de la función de HogarSegu- 
ro leer el estado del sensor no tiene nada que ver con 
la forma física de los datos o el tipo de sensor que se 
emplea. De hecho, se podría argumentar que leer esta- 
do sería un nombre más apropiado para esta función, ya 
que ignora totalmente los detalles del mecanismo de 
entrada. Igualmente, un modelo de datos esencial del 
elemento datos número de teléfono (implicado en la 
función marcar número de teléfono) puede represen- 
tarse en esta fase independientemente de la estructura 
de los datos (si es que hay alguna) usada para imple- 
mentar el elemento datos. Enfocando nuestra atención 
en la esencia del problema en las primeras fases del aná- 
lisis de requisitos, dejamos abiertas nuestras opciones 
para especificar los detalles de implementación duran- 
te fases posteriores de especificación de requisitos y 
diseño del software. 


MEN 


Evita la tentación de trasladarte directamente al punta 
de vista de implementación, entendiendoque lo esencia 
del problema es obvia. El especificar demasiado rápido 
la implementación en detalle reduce tus alternativas 

e incremento el riesgo. 


La visión de implementación de los requisitos del 
software introduce la manifestación en el mundo real 
de las funciones de procesamiento y las estructuras 
de la información. En algunos casos, se desarrolla una 
representación física en la primera fase del diseño del 
software. Sin embargo, la mayoría de los sistemas 
basados en computadora se especifican de manera que 


7 Mucha gente utiliza términos visión «lógica» y «física» para referirse 
al mismo concepto. 
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se acomode a ciertos detalles de implementación. Un 
dispositivo de entrada de información a HogarSegu- 
ro podría ser un sensor de perímetro (no un perro guar- 
dián, un guardia de seguridad o una trampa). El sensor 
detecta una entrada no autorizada al detectar una rup- 
tura en un circuito electrónico. Las características 
generales del sensor deberían tenerse en cuenta como 
parte de la especificación de los requisitos del soft- 
ware. El analista debe reconocer las restricciones 
impuestas por elementos predefinidos del sistema (el 
sensor) y considerar la visión de implementación de 
la función y de la información cuando tal visión es 
apropiada. 

Ya hemos comentado anteriormente que el análisis 
de los requisitos del software debería concentrarse en 
qué es lo que debe hacer el software, en vez de cómo 
se implementará el procesamiento. Sin embargo, la 
visión de implementaciónno debería interpretarse nece- 
sariamente como una representación del cómo. Más 
bien, un modelo de implementación representa el modo 
actual de operación, es decir, la asignación existente o 


propuesta de todos los elementos del sistema. El mode- 
lo esencial (de función o datos) es genérico en el senti- 
do de que la realización de la función no se indica 
explícitamente. 


Sotfware de HogarSeguro 


O 


Configurar Monitorizar Interactuar 
sistema sensores con el usuario 

| Rastreo Activar 

E de sucesos las funciones 

Í del sensor de la alarma 

Leer Identificar  Activar/ Activar Marcar 
el estado eltipo desactivar la alarma el número 
delsensor desuceso  elsensor sonora de teléfono 


FIGURA 11.5. Partición vertical de la función de HogarSeguro. 


El análisis hay que hacerlo independientemente del para- 
digma de ingeniería del software que se aplique. Sin 
embargo, la forma que toma este análisis varía. En algu- 
nos casos es posible aplicar los principios operativos 
del análisis y obtener un modelo de software del que se 
pueda desarrollar un diseño. En otras situaciones, se rea- 
lizan recopilaciones de requisitos (por TFEA, DFC u 
otras técnicas de «tormenta de ideas» [JOR 897), se apli- 
can los principios del análisis y se construye un mode- 
lo del software a fabricar denominado prototipo para 
que lo valore el cliente y el desarrollador. Finalmente, 
hay circunstancias que requieren la construcción de un 
prototipo al comienzo del análisis, ya que el modelo es 
el único medio a través del cual se pueden obtener efi- 
cazmente los requisitos. El modelo evoluciona después 
hacia la producción del software. 


pl 


dores pueden construir y probar 
nes, pero los usuarios son los que 
icepton o rechazan la operativa actual. 


11.4.1. Selección del enfoque de creación de 
prototipos 


El paradigma de creación de prototipos puede ser cerra- 
do o abierto. El enfoque cerrado se denomina a menu- 
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doprototipo desechable. Este prototipo sirve únicamente 
como una basta demostración de los requisitos. Después 
se desecha y se hace una ingeniería del software con un 
paradigma diferente. Un enfoque abierto, denominado 
prototipo evolutivo, emplea el prototipo como primera 
parte de una actividad de análisis a la que seguirá el dise- 
ño y la construcción. El prototipo del software es la pr+ 
mera evolución del sistema terminado. 


¿ Qué debemos mirar para 
determinar si un prototipo 
es o no una alternativa viable? 


Antes de poder elegir un enfoque abierto o cerrado, 
es necesario determinar si se puede crear un prototipo 
del sistema a construir. Se pueden definir varios facto- 
res candidatosa la creación de prototipos [BOA84]: área 
de aplicación, complejidad, características del cliente y 
del proyecto". 

En general, cualquier aplicación que cree panta- 
llas visuales dinámicas, interactúe intensamente con 
el ser humano, o demande algoritmos o procesamiento 
de combinaciones que deban crearse de manera pro- 
gresiva, es un buen candidato para la creación de un 
prototipo. Sin embargo, estas áreas de aplicación 
deben ponderarse con la complejidad de la aplica- 
ción. Si una aplicación candidata (una con las carac- 
terísticas reseñadas anteriormente) va a requerir el 
desarrollo de decenas de miles de líneas de código 


$ Se puede encontrar otro útil estudio sobre los factores candidatos 
de «cuando hacer un prototipo» en (DAV95b]. 
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antes de poder realizar cualquier función demostra- 
ble, es muy probable que sea demasiado compleja 
para crear un prototipo”. Si se puede hacer una par- 
tición a su complejidad, puede ser posible crear pro- 
totipos de porciones del software. 

Como el cliente debe interactuar con el prototipo 
en fases posteriores, es esencial que (1) se destinen 
recursos del cliente a la evaluación y refinamiento del 
prototipo, y (2) el cliente sea capaz de tomar decisio- 
nes inmediatas sobre los requisitos. Finalmente, la 
naturaleza del proyecto de desarrollo tendrá una gran 
influencia en la capacidad de crear un prototipo. ¿Desea 
y es capaz la gestión del proyecto de trabajar con el 
método del prototipo? ¿,Tenemos disponibles herra- 
mientas para la creación de prototipos? ¿Tienen expe- 
riencia los desarrolladores con los métodos de creación 
de prototipos? Andriole [AND92] sugiere un conjun- 
to de seis preguntas (Fig. 11.6)e indica unos conjun- 
tos básicos de respuestas con su correspondiente tipo 
de prototipo sugerido. 


11.4,2, Métodos y herramientaspara el desarrollo 
de prototipos 


Para que la creación del prototipo de software sea efec- 
tivo, debe desarrollarse rápidamente para que el clien- 
te pueda valorar los resultados y recomendar los cambios 
oportunos. Para poder crear prototipos rápidos, hay dis- 
ponibles tres clases genéricas de métodos y herramien- 
tas (por ejemplo, [AND92], [TAN39])): 


Técnicas de Cuarta Generación. Las técnicas de cuar- 
ta generación (T4G) comprenden una amplia gama de 
lenguajes de consulta e informes de bases de datos, gene- 
radores de programas y aplicaciones y de otros lenguajes 
no procedimentales de muy alto nivel. Como las técnicas 
T4G permiten al ingeniero del software generar código eje- 
cutable rápidamente, son ideales para la creación rápida 
de prototipos. 


Componentes de software reutilizables. Otro enfoque 
para crear prototipos rápidos es ensamblar, más que cons- 
truir, el prototipo mediante un conjunto de componentes soft- 
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ware existentes. La combinación de prototipos con la reuti- 
lización de componentes de programa sólo funcionará si se 
desarrolla un sistema bibliotecario de manera que los com- 
ponentes existentes estén catalogados y puedan recogerse. 
Debería resaltarse que se puede usar un prodiicto software 
existente como prototipo de un «nuevo y mejorado» pro- 
ducto competitivo. En cierta manera, ésta es una forma de 
reutilización en la creación de prototipos software. 


Especificaciones formales y entornos para prototipos. 
Durante las pasadas dos décadas, se han desarrollado varios 
lenguajes formales de especificación y herramientas como 
sustitutos de las técnicas de especificación con lenguajenatu- 
ral. Hoy en día, los desarrolladores de estos lenguajes for- 
males están desarrollando entornos interactivos que (1) 
permitan al analista crear interactivamente una especifica- 
ción basada en lenguaje de un sistema o software, (2) invo- 
quen herramientas automáticas que traducen la especificación 
basada en el lenguaje en código ejecutable, y (3) permitan 
al cliente usar el código ejecutable del prototipo para refinar 
los requisitos formales. 


Trabajo 
preliminar 
Prototipo Prototipo adicional 
Pregunta desechable evolutivo requerido 
¿Se entiende el dominio , > 
de la aplicación? SÍ SÍ No 
¿Se puede modelar y E 
el problema? Sí Sí No 
¿Está el cliente 
suficientemente seguro 
de los requisitos 
básicos del sistema? Si/No Si/No No 
¿Están establecidos 
los requisitos > > 
y son estables? No SÍ Ss 
¿Hay requisitos A 
¿Hay 1 » 
ambiguos? SÍ No Sí 
¿Hay contradicciones pr Z 
en los requisitos? Sl No Sí 


FIGURA 11.6. Selección del enfoque apropiado de creación 
de prototipo. 


Nohay duda de que el modo de especificacióntiene mucho 
que ver con la calidad de la solución. Los ingenieros del 
software que se han visto forzados a trabajar con especi- 
ficaciones incompletas, inconsistentes o engañosas han 
experimentado la frustración y confusión que invariable- 
mente provocan. La calidad, la fecha de entrega y el alcan- 
ve del software son las que sufren las consecuencias. 


¿En algunos casos, se pueden construir rapidamente prototipos extre- 
madamente complejos usando técnicas de cuarta generacion o com- 
ponentes software reutilizables 
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Conv 


En muchos casos, no es razonable plantearse 
que la especificacióndeberácontrastarse con todo 
Debemos capturar lo esencia de lo que el cliente solicito. 
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11.5.1. Principios de la especificación 


La especificación, independientemente del modo como 
la realicemos, puede verse como un proceso de repre- 
sentación. Los requisitos se representan de manera que 
como fin último lleven al éxito de la implementación 
del software.A continuación, se proponen algunos prin- 
cipios de especificación adaptados del trabajo de Bal- 
zer y Goldman [BAL386]: 


1. Separar la funcionalidad de la implementación. 


2. Desarrollar un modelo del comportamiento deseado 
de un sistema que comprenda datos y las respuestas 
funcionales de un sistema a varios estímulos del 
entorno. 

. Establecerel contexto en que opera el software espe- 
cificando la manera en que otros componentes del 
sistema interactúan con él. 

Definir el entorno en que va a operar el sistemae indi- 
car como «una colección de agentes altamente entre- 
lazados reaccionan a estímulos del entorno (cambios 
de objetos) producidos por esos agentes»[BAL86]. 
Crear un modelo intuitivo en vez de un diseño o 
modelo de implementación. 


Reconocer que «la especificación debe ser tolerante 
a un posible crecimiento si no es completa». Una 
especificación es siempre un modelo —una abs- 
tracción — de alguna situación real (o prevista) que 
normalmente suele ser compleja. De ahí que será 
incompleta y existirá a muchos niveles de detalle. 


. Establecer el contenido y la estructura de una espe- 
cificación de manera que acepte cambios. 


Esta lista de principios básicos proporciona la base 
para representar los requisitos del software. Sin embar- 
go, los principios deben traducirse en realidad. En la 
siguiente sección examinamos un conjunto de directri- 
ces para la creación de una especificación de requisitos. 


11.5.2, Representación 


Ya hemos visto que los requisitos del software pue- 

den especificarse de varias maneras. Sin embargo, si 

los requisitos se muestran en papel o en un medio elec- 

trónico de representación (¡y debería ser casi siempre 

así!), merece la pena seguir este sencillo grupo de 
¿Cuáles son las directrices 


directrices: 
? básicas fundamentales para 


representar los requisitos? 


El formato de la representación y el contenido deberían 
estar relacionados con el problema. Se puede desarrollar un 
esbozo general del contenidode la especificación de los requi- 
sitos del software. Sin embargo, las formas de representación 
contenidasen la especificación es probable que varíen con el 
área de aplicación. Por ejemplo.!«. especificación de un siste- 
ma automático de fabricación utilizaría diferente simbología, 
diagramas y lenguaje que la especificaciónde un compilador 
de un lenguaje de programación. 
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La informacióncontenida dentro de la especificación debe- 
ría estar escalonada. Las representaciones deberían revelar 
capas de informaciónde manera que el lector se pueda mover 
en el nivel de detalle requerido. La numeración de párrafos y 
diagramasdebería indicar el nivel de detalle que se muestra.A 
veces, merece la pena presentar la misma informacióncon dife- 
rentes niveles de abstracción para ayudar a su comprensión. 


Los diagramas y otrasformas de notación deberían res- 
tringirseen númeroy ser consistentes en su empleo. Las nota- 
ciones confusas o inconsistentes, tanto gráficas como 
simbólicas, degradan la comprensión y fomentan errores. 


Las representaciones deben permitir revisiones. Segura- 
menteel contenido de una especificacióncambiará. Idealmente, 
debería haber herramientas CASE disponibles para actualizar 
todas las representaciones afectadas por cada cambio. 


Los investigadores han llevado a cabo numerosos 
estudios (por ejemplo, [HOL95], [CUR85]) sobre los 
factores humanos asociados con la especificación. Pare- 
ce haber pocas dudas de que la simbología y la distri- 
bución afectan a la comprensión. Sin embargo, los 
ingenieros del software parecen tener preferencias indi- 
viduales por especificaciones simbólicas y diagramas 
específicos. La familiaridad es a menudo la raíz de las 
preferencias de una persona, pero otros factores más 
tangibles tales como la disposición espacial, formas 
fácilmente reconocibles y el grado de formalidad dic- 
tan normalmente la elección individual. 


11.53. La especificación de los requisitos del 
software 


La especificación de los requisitos del software se pro- 
duce en la culminación de la tarea de análisis. La fun- 
ción y rendimiento asignados al software como parte de 
la ingeniería de sistemas se retinan estableciendo una 
completa descripción de la información, una descrip- 
ción detallada de la función y del comportamiento, una 
indicación de los requisitos del rendimiento y restric- 
ciones del diseño, criterios de validación apropiados y 
otros datos pertinentes a los requisitos. 


Especificación de Requis tos Software 


La Introducción a la especificación de los requisitos 
del softwareestablece las metas y objetivos del software, 
describiéndoloen el contexto del sistema basado en com- 
putadora. De hecho, la Introducción puede no ser más que 
el alcancedel softwareen el documento de planificación. 

La Descripción de la información proporciona una 
detallada descripción del problema que el software va 
a resolver. Se documentan el contenido de la informa- 
ción y sus relaciones, flujo y estructura. Se describen 
las interfaces hardware, software y humanas para los 
elementos extemos del sistema y para las funciones 
internas del software. 
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En la Descripción funcional se describen todas las 
funciones requeridas para solucionar el problema. Se 
proporciona una descripción del proceso de cada fun- 
ción; se establecen y justifican las restricciones del dise- 
fío, se establecen las características del rendimiento; y 
se incluyen uno O más diagramas para representar grá- 
ficamente la estructura global del software y las inte- 
racciones entre las funciones software y otros elementos 
del sistema. La sección de las especificaciones Des- 
cripción del comportamiento examina la operativa del 
software como consecuencia de acontecimientos exter- 
nos y características de control generadas internamente. 


Ronsuo) 


Cuando desorrolles criterios de validación, responde 
a lo siguiente cuestión: «Cómo reconocer si un sistema 
és correcto si no lo muevo de mimesa?» 


Probablemente la más importante, e irónicamente, 
la sección más a menudo ignorada de una especifica- 
ción de requisitos del software son los Criterios de vali- 
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dación. ¿Cómo reconocemos el éxito de una imple- 
mentación? ¿Qué clases de pruebas se deben llevar a 
cabo para validar la función, el rendimiento y las res- 
tricciones? Ignoramos esta sección porque para com- 
pletarla se necesita una profunda comprensión de los 
requisitos del software, algo que a menudo no posee- 
mos en esta fase. Sin embargo, la especificación de los 
criterios de validación actúa como una revisión implí- 
cita de todos los demás requisitos. Es esencial invertir 
tiempo y prestar atención a esta sección. Finalmente, la 
especificación incluye una Bibliografía y un Apéndice. 

En muchos casos la Especificación de requisitos del 
software puede estar acompañada de un prototipo eje- 
cutable (que en algunos casos puede sustituir a la espe- 
cificación), un prototipo en papel o un Manual de 
usuario preliminar. El Manual de usuario preliminar 
presenta al software como una caja negra. Es decir, se 
pone gran énfasis en las entradas del usuario y las sali- 
das (resultados)obtenidas. El manual puede servir como 
una valiosa herramienta para descubrir problemas en la 
interfaz hombre-máquina. 


La revisión de la Especificación de requisitos del soft- 
ware (y/o prototipo) es llevada a cabo tanto por el desa- 
rrollador del software como por el cliente. Como la 
especificación forma el fundamento para el diseño y las 
subsiguientes actividades de la ingeniería del software, 
se debería poner extremo cuidado al realizar la revisión. 


El 


Requisitos Software 
Revisiónde lo Especificación 


Inicialmente la revisión se lleva a cabo a nivel 
macroscópico. Á este nivel, los revisores intentan ase- 
gurarse de que la especificación sea completa, con- 
sistente y correcta cuando la información general, 
funcional y de los dominios del comportamiento son 
considerados. Asimismo, una exploración completa de 
cada uno de estos dominios, la revisión profundiza en 
el detalle, examinando no solo las descripciones super- 
ficiales, sino la vía en la que los requisitos son expre- 
sados. Por ejemplo, cuando una especificación contiene 
un «término vago» (por ejemplo, algo, algunas veces, 
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a veces, normalmente, corrientemente, mucho, o prin- 
cipalmente), el revisor señalará la sentencia para su 
clarificación. 

Una vez que se ha completado la revisión, se fir- 
ma la especificación de requisitos del software por el 
cliente y el desarrollador. La especificación se con- 
viene en un «contrato» para el desarrollo del softwa- 
re. Las peticiones de cambios en los requisitos una 
vez que se ha finalizado la especificación no se eli- 
minarán, pero el cliente debe saber que cada cambio 
a posteriori significa una ampliación del ámbito del 
software, y por tanto pueden aumentar los costes y 
prolongar los plazos de la planificación temporal del 
proyecto. 

Incluso con los mejores procedimientos de revisión, 
siempre persisten algunos problemas comunes de espe- 
cificación. La especificación es difícil de «probar» de 
manera significativa, por lo que pueden pasar inadver- 
tidas ciertas inconsistencias y omisiones. Durante la 
revisión, se pueden recomendar cambios a la especifi- 
cación. Puede ser extremadamente difícil valorar el 
impacto global de un cambio; es decir, ¿cómo afecta el 
cambio en una función a los requisitos de las demás? 
Los modernos entornos de ingeniería del software (Capí- 
tulo 31) incorporan herramientas CASE desarrolladas 
para ayudar a resolver estos problemas. 
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El análisis de requisitos es la primera fase técnica del 
proceso de ingenieríadel software. En este punto se refi- 
na la declaración general del ámbito del software en una 
especificación concreta que se convierte en el funda- 
mento de todas las actividades siguientes de la inge- 
niería del software. 

El análisis debe enfocarse en los dominios de la 
información, funcional y de comportamiento del pro- 
blema. Para entender mejor lo que se requiere, se crean 
modelos, los problemas sufren una partición y se desa- 
rrollan representaciones que muestran la esencia de los 
requisitos y posteriormente los detalles de la imple- 
mentación. 


En muchos casos, no es posible especificar completa- 
mente un problema en una etapa tan temprana. La crea- 
ción de prototipos ofrece un enfoque alternativo que 
produce un modelo ejecutable del software en el que 
se pueden refinar los requisitos. Se necesitan herra- 
mientas especiales para poder realizar adecuadamente 
la creación de prototipos. 

Como resultado del análisis, se desarrolla la Especi- 

ficación de requisitos del software. La revisión es esen- 
cial para asegurarse que el cliente y el desarrollador 
tienen el mismo concepto del sistema. Desgraciada- 
mente, incluso con los mejores métodos, la cuestiónes 
que el problema sigue cambiando. 
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PROBLEMAS Y PUNTOS.A CONSIDERAR 


11.1.El análisis de requisitos del software es indudablemente 
la fase de comunicación más intensa del proceso de ingenie- 
ría del software. ¿Por qué suele romperse frecuentemente este 
enlace de comunicación? 


11.2. Suele haber serias repercusiones políticas cuando 
comienza el análisis de requisitos del software (y/o análisis 
de un sistema). Por ejemplo, los trabajadores pueden creer 
que la seguridad de su trabajo puede verse amenazada por un 
nuevo sistema automático. ¿Qué origina tales problemas? ¿Se 


pueden llevar a cabo las tareas de análisis de manera que se 
minimicen estas repercusiones políticas? 


11.3. Estudie su percepción ideal de la formación y currícu- 
lum de un analista de sistemas. 


11.4.A lolargo de todo el capítulo nos referimos al «clien- 
te». Describa el «cliente» desde el punto de vista de los 
desarrolladores de sistemas de información, de los cons- 
tructores de productos basados en computadora y de los 
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constructores de sistemas. ¡Tenga cuidado, el problema pue- 
de ser más complejo de lo que parece! 


11.5. Desarrolle un «kit» de técnicas de especificación de apli- 
cación (TFEA). El kit debería incluir un conjunto de directri- 
ces para llevar a cabo una reunión TFEA, materiales para 
facilitar la creación de listas y otros elementos que pudieran 
ayudar en la definición de requisitos. 


*11.6. Su profesor dividirá la clase en grupos de cuatro a seis 
estudiantes. La mitad del grupo hará el papel del departamento 
ide marketing y la otra mitad el de la ingeniería del software. 
'"Surabajo consiste en definir los requisitos del sistema de segu- 
ridad HogarSeguro descrito en este capítulo. Celebre una reu- 
nión TFEA usando las directrices estudiadas en el capítulo. 


11.7, ¿Se puede decir que un Manual preliminar de usuario 
es una forma de prototipo? Razone su respuesta. 


11.8. Analice el dominio de información de HogarSeguro. 
¿Represente (usando la notación que crea apropiada) el flujo, 
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el contenido y cualquier estructura de la información que le 
parezca relevante. 

11.9. Haga una partición del dominio funcional de HogarSe- 
guro. Inicialmente haga una partición horizontal; después haga 
la partición vertical. 

11.10. Construya la representación esencial y de implemen- 
tación del sistema HogarSeguro. 

11.11, Construya un prototipo en papel (o uno real) de Hogar- 
Seguro. Asegúrese de mostrar la interacción del propietario y 
el funcionamiento global del sistema. 

11.12. Intente identificar componentes software de Hogar- 
Seguro que podrían ser «reutilizables» en otros productos o 
sistemas. Intente clasificar esos componentes. 

11.13, Desarrolle una especificación escrita de HogarSegu- 
ro usando el esquema propuesto en la página web SEPA. (Nota: 
Su profesor le sugerirá qué secciones completar en este 
momento.) Asegúrese de aplicar las cuestiones descritas en la 
revisión de la especificación. 


Los libros que indicamos sobre la ingeniería de requisitos per- 
míten una buena base para el estudio de los conceptos y prin- 
cipios básicos del análisis. Thayer y Dorfman (Software 
Requirements Engineering, 2.* ed., IEEE Computer Society 
Press, 1997) presentan una amplía antología sobre el tema. 
Graham y Graham (Requirements Engineering and Rapid 
Development, Addison-Wesley, 1989,destacael desarrollorápi- 
db y el uso de métodos orientados a objetos en su planteamiento 
sobre la ingeniería de requisitos, mientras MacCauley (Requi- 
rements Engineering, Springer Verlag, 1996) presenta un bre- 
ve tratado académico sobre el tema. 

En los últimos años, la literatura hacia énfasis en el 
modelo de requisitos y en los métodos de especificación, 
pero hoy se hace igual énfasis en los métodos eficientes 
para la obtención de requisitos del software. Wood y Sil- 
wer (JointApplication Development, segunda edición, Wiley, 
1995) han escrito un tratado definitivo para el desarrollo 
de aplicacionesenlazadas. Cohen y Cohen (Quality Function 
Deployment, Addison-Wesley, 1995), Terninko (Step-By- 
Step OFD: Customer-Driven Product Design, Saint Lucie 
Press, 1997), Gause y Weinberg [GAUS89] y Zahniser 
[ZAH9O] estudia los mecanismos para tener reuniones efec- 
tivas, métodos de brainstorming y obtención de requisitos 
que pueden usarse para clarificar resultados y una variedad 
de otras necesidades. Los casos de uso configuran una par- 
te importante del análisis de requisitos orientado a objetos, 
fue pueden usarse de forma independiente de la imple- 
inentación tecnológica que se seleccione. Rosenburg y Scott 
(Use-CaseDriven Ohject Modelling with UML: A Practt- 
cal Approach, Addison-Wesley, 1999), Schneider et al. 
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(Applying Use-cases: A Practical Guide, Addison-Wesíey, 
1998), y Texel y Williams (Use-Cases Combined With 
Booch/OMT/UML, Prentice-Hall, 1997) facilitan una guía 
detallada y muchos ejemplos Útiles. 

El análisis del dominio de la información es un principio 
fundamental del análisis de requisitos. Los libros de Matti- 
son (The Object-Oriented Enterprise, McGraw-Hill, 1993), 
y Modell (DataAnalysis, Data Modelling and Classification, 
McGraw-Hill, 1992) cubre distintos aspectos de este impor- 
tante tema. 

Un reciente libro de Harrison (Prototyping and Software 
Development, Springer Verlag, 1999) facilita una moderna 
perspectiva sobre el prototipado del software. Dos libros de 
Connell y Shafer (Structured Rapid Prototyping, Prentice- 
Hall, 1989) y (Object-Oriented Rapid Prototyping, Yourdon 
Press, 1994) muestra como esta importante técnica de análi- 
sis puede ser utilizada tanto para entornos convencionales 
como para entornos orientados a objetos. 

Otros libros como los de Pomberger et al. (Object Orien- 
tation and Prototyping in Software Engineering, Prentice- 
Hall, 1996) y Krief et al. (Prototyping With Objects, 
Prentice-Hall, 1996) examina el prototipado desde la pers- 
pectiva de la orientación a objetos. La IEEE Proceedings of 
International Workshop on Rapid System Prototyping (publi- 
cado el pasado año) presenta una visión actual en esta área. 

Una amplía variedad de fuentes de información sobre el 
análisis de requisitos y otros temas relacionados están dispo- 
nibles en intemet. Una lista actualizada de páginas web que 
son significativas sobre los conceptos y métodos de análisis 
se encuentran en http://www.pressman5.com 
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CAPÍTULO 
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MODELADO DEL ANÁLISIS 


N un nivel técnico, la ingeniería del software empieza con una serie de tareas de mode- 

lado que llevan a una especificación completa de los requisitos y a una representación 

del diseño general del software a construir. El modelo de análisis, realmente un conjunto 
de modelos, es la primera representación técnica de un sistema. Con los años se han propuesto 
muchos métodos para el modelado del análisis. Sin embargo, ahora dos tendencias dominan el 
panorama del modelado del análisis. El primero, análisis estructurado, es un método de mode- 
lado clásico y se describe en este capítulo. El otro enfoque, análisis orientado a objetos, se estu- 
dia con detalle en el Capítulo 21. En la Sección 12.8 se presenta una breve visión general de 
otros métodos de análisis comúnmente usados. 

El análisis estructurado es una actividad de construcción de modelos. Mediante una nota- 
ción que satisfaga los principios de análisis operacional estudiada en el Capítulo 11, creamos 
modelos que representan el contenido y flujo de la información (datos y control); partimos el 
sistema funcionalmente, y según los distintos comportamientos establecemos la esencia de;lo 
que se debe construir. El análisis estructurado no es un método sencillo aplicado siempre dela 
misma forma por todos los que lo usan. Más bien, es una amalgama que ha evolucionado duran- 
te los últimos 30 años. 

En su principal libro sobre este tema, Tom DeMarco [DEM79] describe el análisis estruc- 
turado de la siguiente forma: 


VISTAZO RÁPIDO 


| 
| 
| 
| 


¿us es? La palabra escrita es un vehícu- 


lo maravilloso para la comunicación, 
pero no es necesariamente el mejor 
camino para representarlos requisitos 
del software.El análisis utilizauna com- 
binación de texto y de diagramas, para 
representar los requisitos de datos, fun- 


ciones y comportamientos, que es rela- 
tivamente fácil de entender y, más 


importante aún, Sencillo para revisar su 
corrección, completitud y consistencia. 


¿Quién lo hace? El ingenierodel software 


(aveces llamado analista) construye el 
modelo utilizando los requisitos defini- 
dos por el cliente. 


¿Por qué es importante? Para validar los 


requisitos del software necesitamos 
examinarlos desde diferentespuntosde 


vista. El análisis representa los requi- 
sitos en tres «dimensiones», por esa 
razón, seincrementala probabilidad de 


encontrar errores, descubrir inconsis- 
tencias y detectar omisiones. 


son los pasos? Los requisitos de 
datos, funciones Y comportamientos 
son modelados utilizando diferentes 
diagramas. El modelado de datos defi- 
ne objetos de datos, atributos y rela- 
ciones. El modelado de funciones 
indica COMO los datos son transforma- 


dos dentro del sistema. El modelado 
del comportamiento representa el 


impactode los sucesos. Se crean unos 
modelos preliminares que son anali- 
zados y refinados para valorar su cla- 
ridad. completitud y consistencia. Una 


especificación incorporada en el mode- 
loes creada y luego validada, tanto por 
el ingenierodel software, como por los 
clientes/usuarios, 


¿Cuál es el producto obtenido? Las des- 


cripciones de los objetos de datos, los 
diagramas entidad-relación, los dia- 
gramas de flujo de datos, los diagra- 
mas de transición de estados, las 
especificaciones del proceso y las 
especificaciones de control son creas 
das comoresultado delas actividades 
del análisis. 


¿Cómo puedo estar seguro de que lo he 


hecho correctamente?El resultado del 
modelado del análisis debe serrevisa- 
dopara verificar sucorrección,comple- 
titud y consistencia. 


Observando los problemas y fallos reconocidos para la fase de análisis, se puede sugerir que necesita- 
mos añadir los siguientes objetivos a la fase de análisis. 


+ Los productos del análisis han de ser de mantenimiento muy fácil. Esto concierne concretamente al 


documento final [Especificación de Requisitos del Software]. 
» Se deben tratar los problemas de gran tamaño mediante algún método efectivo de partición. La espe- 
cificación mediante novelas victorianas ya no sirve. 
» Siempre que sea posible, se deben utilizar gráficos. 


* Tenemos que diferenciar las consideraciones lógicas [esenciales] y las físicas [de implementación). .. 


Como mínimo, necesitamos .... 


» Algo que nos ayude a hacer una partición de los requisitos y a documentar esas divisiones antes de 
especificar ... 


» Algún método de seguimiento y evaluación de interfaces ... 
» Nuevas herramientas para describir la lógica y la táctica, algo mejores que descripciones narrativas ... 
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Es muy probable que ningún otro método de ingeniería del software haya generado tanto interés, haya sido pro- 
bado (y a veces rechazado y vuelto a probar) por tanta gente, criticado y haya provocado tanta controversia. Pero 
el método ha subsistido y ha alcanzado un importante seguimiento dentro de la comunidad de la ingeniería del 


software. 


Al igual que muchas de las contribuciones importan- 
tes a la ingeniería del software, el análisis estructurado 
no fue introducido en un solo artículo o libro clave que 
incluyera un tratamiento completo del tema. Los pri- 
meros trabajos sobre modelos de análisis aparecieron a 
finales de los 60 y principios de los 70, pero la prime- 
ra aparición del enfoque de análisis estructurado fue 
como complemento de otro tema importante —el «dise- 
ño estructurado» —. Los investigadores (por ejemplo, 
[STE74], [Y0U78], necesitaban una notación gráfica 
para representar los datos y los procesos que los trans- 
forman. Esos procesos quedarían finalmente estableci- 
dos en una arquitectura de diseño. 


n problemas. 


perar que vengan y pensa 
ses ún problemo. 


El término «análisis estructurado» originalmente 
acuñado por Douglas Ross, fue popularizado por 
DeMarco [DEM?79]. En su libro sobre esta materia, 
DeMarco presentó y denominó los símbolos gráficos y 
los modelos que los incorporan. En los años siguientes, 
Page-Jones [PAG80], Gane y Sarson [GAN82] y 
muchos otros propusieron variaciones del enfoque del 
análisis estructurado. En todos los casos, el método se 
centraba en aplicaciones de sistemas de información y 
no proporcionaba una notación adecuada para los aspec- 
tos de control y de comportamiento de los problemas 
de ingeniería de tiempo real. 

A mediados de los 80, las «ampliaciones» para tiem- 
po real fueron introducidas por Ward y Mellor [WAR85] 
y, más tarde, por Hatley y Pirbhai [HAT87]. Con esas 
ampliaciones, se consiguió un método de análisis más 
robusto que podía ser aplicado de forma efectiva a pro- 
blemas de ingeniería. En la actualidad, se está inten- 
tando desarrollar una notación consistente [BRU88] y 
se están publicando tratamientos modernos que permi- 
tan acomodar el uso de herramientas CASE [YOUS89). 


El modelo de análisis debe lograr tres objetivos pri- 
marios: (1) describir lo que requiere el cliente, (2) esta- 
blecer una base para la creación de un diseño de 
software, y (3) definir un conjunto de requisitos que 
se pueda validar una vez que se construye el softwa- 
re. Para lograr estos objetivos, el modelo de análisis 
extraído durante el análisis estructurado toma la for- 
ma ilustrada en la Figura 12.1. 

En el centro del modelo se encuentra el dicciona- 
rio de datos —um almacén que contiene definiciones 
de todos los objetos de datos consumidos y produci- 
dos por el software —. Tres diagramas diferentes ro- 
dean el núcleo. El diagrama de entidad-relación (DER) 
representa las relaciones entre los objetos de datos. El 
DER es la notación que se usa para realizar la activi- 
dad de modelado de datos. Los atributos de cada obje- 
to de datos señalados en el DER se puede describir 
mediante una descripción de ohjetos de datos. 

El diagrama de flujo de datos (DFD) sirve para 
dos propósitos: (1) proporcionar una indicación de 
cómo se transforman los datos a medida que se avan- 
za en el sistema, y (2) representar las funciones (y 
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Diagrama Diagrama 
de flujo 


de datos 


FIGURA 12.1. La estructura del modelo de análisis. 


subfunciones) que transforman el flujo de datos. El 
DFD proporciona información adicional que se usa 
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durante el análisis del dominio de información y sir- 
ve como base para el modelado de función. En una 
especificaciónde proceso (EP )se encuentra una des- 
cripción de cada función presentada en el DFD. 

El diagrama de transición de estados (DTE )indica 
cómo se comporta el sistema como consecuencia de 
sucesos externos. Para lograr esto, el DTE representa 
los diferentes modos de comportamiento (llamados esta- 
dos) del sistema y la manera en que se hacen las tran- 


uns: LO 12 MODELADO DEL ANÁLISIS 


siciones de estado a estado. El DTE sirve como la base 
del modelado de comportamiento. Dentro de la especi- 


ficación de control (EC )se encuentra más información 


sobre los aspectos de control del software. 

El modelo de análisis acompaña a cada diagrama, 
especificación y descripción, y al diccionario señalado 
en la Figura 12.1.Un estudio más detallado de estos ele- 
mentos del modelo de análisis se presenta en las sec- 
ciones siguientes. 


El modelado de datos responde a una serie de pregun- 
tas específicas importantes para cualquier aplicación de 
procesamiento de datos. ¿Cuáles son los objetos de datos 
primarios que va a procesarel sistema? ¿Cuál es la com- 
posición de cada objeto de datos y qué atributos des- 
cribe el objeto? ¿Dónde residen actualmente los objetos? 
¿Cuál es la relación entre los objetos y los procesos que 
los transforman? 


" da respuesta el modelo 
de datos? 


Para responder estas preguntas, los métodos de mode- 
lado de datos hacen uso del diagrama de entidad-rela- 
ción (DER). El DER, descrito con detalle posteriormente 
en esta sección, permite que un ingeniero del software 
identifique objetos de datos y sus relaciones mediante 
una notación gráfica. En el contexto del análisis estruc- 
turado, el DER define todos los datos que se introdu- 
cen, se almacenan, se transforman y se producen dentro 
de una aplicación. 


aproximación ER está en lo hobilidad 
mtidades de negocio del mundo real y 


El diagrama entidad-relación se centra solo en los 
datos (y por consiguiente satisface el primer principio 
operacional de análisis), representando una «red de 
datos» que existe para un sistemadado. El DER es espe- 
cíficamente Útil para aplicaciones en donde los datos y 
las relaciones que gobiernan los datos son complejos. 
A diferencia del diagrama de flujo de datos (estudiado 
en la Sección 12.4 y usado para representar como se 
transforman los datos), el modelado de datos estudia 
los datos independientemente del procesamiento que 
los transforma. 
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Atributos: Relaciones: 


Objetos: 


Nombre 
Dirección 
Edad 


Licencia 
de conducir 


Número 


Fabricante 
Modelo 


Número 
de bastidor 


Tipo de 
carrocería 


Color 


FIGURA 12.2. Objetos de datos, atributos y relaciones. 


12.3.1. Objetos de datos, atributos y relaciones 


El modelo de datos se compone de tres piezas de infor- 
mación interrelacionadas: el objeto de datos, los atri- 
butos que describen el objeto de datos y la relación que 
conecta objetos de datos entre sí. 


Objetos de datos. Un objeto de datos es una repre- 
sentación de cualquier composición de informacióncom- 
puesta que deba comprenderel software. Por composición 
de información, entendemos todo aquello que tiene un 
número de propiedades o atributos diferentes. Por tanto, 
el «ancho» (un valor sencillo)no sería un objeto de datos 
válido, pero las «dimensiones» (incorporando altura, 
ancho y profundidad) se podría definir como objeto. 


CLAVE 


Un objeto de datos es una representación 
de cualquier configuraciónde información 
que es procesada por el software. 


Un objeto de datos puede ser una entidad externa 
(por ejemplo, cualquier cosa que produce o consume 
información), una cosa (por ejemplo, un informe o una 
pantalla), una ocurrencia (por ejemplo, una llamada tele- 
fónica) o suceso (por ejemplo, una alarma), un puesto 
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(por ejemplo, un vendedor), una unidad de la organiza- 
ción (por ejemplo, departamento de contabilidad), o una 
estructura (por ejemplo, un archivo). Por ejemplo, una 
persona o un coche (Fig. 12.2) se pueden ver como un 
objeto de datos en el sentido en que cualquiera se pue- 
de definir según un conjunto de atributos. La descrip- 
ción de objeto de datos incorpora el objeto de datos y 
todos sus atributos. 


Referencia Web 


Información útil sobre el modelo de datos puede 
encontrarse en www.datamodel.org 


Los objetos de datos se relacionan con otros. Por 
ejemplo, persona puede poseer coche, donde la rela- 
ción poseer implica una «conexión» específica entre 
persona y coche. Las relaciones siempre se definen por 
el contexto del problema que se está analizando. 


Un objeto de datos solamente encapsula datos —no0 
hay referencia dentro de un objeto de datos a operacio- 
nes que actúan en el dato'—. Por consiguiente, el obje- 
to de datos se puede representar como una tabla de la 
forma en que se muestra en la Figura 12.3.Los enca- 
bezamientos de la tabla reflejan atributos del objeto. En 
este caso, se define un coche en términos de fabrican- 
te, modelo, número de bastidor, tipo de carrocería, color 
y propietario. El cuerpo de la tabla representa ocurren- 
cias del objeto de datos. Por ejemplo, un Honda CRV 
es una ocurrencia del objeto de datos coche. 


Atributos Ata un objeto de datos a otro, 
identificativos en este caso, el propietario 
PI —ÁáÁA 
Atributos Atributos 
Identificador descriptivos de referencia 


Fabri- N? de 
cante Modelo Bastidor 


Lexus 15400  AB123... 


Ocurrencia | Honda CRV- X456... 
BMW  750iL. XZ765... 


Tipo de 
carrocería Color  Propietaric 
Sedan Blanco RSP 
Todo- 


terreno 
Coupe 


Rojo CCD 
Blanco LJL 
Azul BLF 


Ford Taurus 012445... Sedan 


FIGURA 12.3. Representación tabular del objeto de datos. 


Atributos. Los atributos definen las propiedades 
de un objeto de datos y toman una de las tres caracte- 
rísticas diferentes. Se pueden usar para (1) nombrar 
una ocurrencia del objeto de datos, (2) describir la ocu- 
rrencia, 0 (3)hacer referencias a otra ocurrencia en 
otra tabla. Además, uno o varios atributos se definen 


1 Esta distinción separa el objeto de datos de la clase u objeto defini- 
dos como parte del paradigma orientado a objetos que se estudia en 
la Parte Cuarta de este libro. 
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como un identificador -es decir, el atributo identifi- 
cador supone una «clave» cuando queramos encontrar 
una instancia del objeto de dato—. En algunos casos, 
los valores para los identificadores son únicos, aun- 
que esto no es un requisito. Haciendo referencia al 
objeto de datos coche, un identificador razonable 
podría ser el número de bastidor. 


a 
as 


CLAVE 


los atributos definen un objeto de datos, 
describen sus caracteristicos, y en algunas ocasiones, 
establecen referencias o otros objetos. 


El conjunto de atributos apropiado para un objeto de 
datos dado se determina mediante el entendimiento del 
contexto del problema. Los atributos para coche des- 
critos anteriormente podrían servir para una aplicación 
que usara un Departamentode Vehículos de Motor, pero 
estos atributos serían menos útiles para una compañía 
de automóviles que necesite fabricar software de con- 
trol. En este último caso, los atributos de coche podrían 
incluir también número de bastidor, tipo de carrocería, 
y color, pero muchos atributos adicionales (Por ejem- 
plo: código interior, tipo de dirección, selector de equi- 
pamiento interior, tipo de transmisión) se tendrían que 
añadir para que coche sea un objeto significativo en el 
contexto del control de fabricación. 


» 
a 


CLAVE 


las relaciones indican la manero en que los objetos 
de datos están «conectados» entre sí. 


Relaciones. Los objetos de datos se conectan entre 
síde muchas formas diferentes. Considere dos objetos 
de datos, libro y librería. Estos objetos se pueden repre- 
sentar mediante la notación simple señalada en la Figu- 
ra 12.4a. Se establece una conexión entre libro y librería 
porque los dos objetos se relacionan. Pero, ¿qué son 
relaciones? Para determinar la respuesta, debemos com- 
prender el papel de libro y librería dentro del contexto 
del software que se va construir. Podemos definir un 
conjunto de parejas objeto-relación que definen las rela- 
ciones relevantes. Por ejemplo, 


una librería pide libros 
una librería muestra libros 


* una librería almacena libros 


una librería vende libros 
una librería devuelve libros 
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(a) Una conexión básica entre objetos 


Pide 


Muestra 


Almacena 


Libro Librería 
Vende 
Devuelve 


(b) Relaciones entre objetos 


FIGURA 12.4. Relaciones. 


Las relaciones pide, muestra, almacena y devuelve defi- 
ne las conexionesrelevantes entre libro y librería. La Figu- 
ra 12,4b ilustra estas parejas objeto-relacióngráficamente. 

Es importante destacar que las parejas objeto-rela- 
ción tienen dos direcciones; esto es, se pueden leer en 
cualquier dirección. Una libreríapide libros o los libros 
sonpedidos por una librería”. 


1232 Cardinalidad y modalidad 


Los elementos básicos del modelado de datos - objetos 
de datos, atributos, y relaciones — proporcionan la base 
del entendimiento del dominio de información de un pro- 
blema. Sin embargo, también se debe comprenderla infor- 
mación adicional relacionada con estos elementosbásicos. 

Hemos definido un conjunto de objetos y represen- 
tado las parejas objeto-relación que los limitan. Una 
simple referencia: el objeto X que se relaciona con el 
objeto Y no proporciona información suficiente para 
propósitos de ingeniería del software. Debemos com- 
prender la cantidad de ocurrencias del objeto X que 
están relacionadas con ocurrencias del objeto Y. Esto 
nos conduce al concepto del modelado de datos llama- 
do cardinalidad. 

Cardinalidad. El modelo de datos debe ser capaz 
de representar el número de ocurrencias de objetos que 
se dan en una relación. Tillman [TIL93] define la car- 
dinalidad de una pareja objeto-relación de la forma 
siguiente: 

La cardinalidad es la especificación del número de 
ocurrencias [de un objeto] que se relaciona con ocu- 
rrencias de otro [objeto]. La cardinalidad normalmente 
se expresa simplemente como «uno» o «muchos». Por 
ejemplo, un marido puede tener solo una esposa (en la 
mayoría de las culturas), mientras que un padre puede 
tener muchos hijos. Teniendo en consideracióntodas las 
combinaciones de «uno» y «muchos», dos [objetos] se 
pueden relacionar como: 


? Para evitar cualquier ambiguedad, se debe considerarla manera en 
qe se etiqueta una relación. Por ejemplo, si no se considera el con- 
texto para una relación bidireccional, la Figura 12 4b podría inter- 
pretarse erróneamente como libros piden librerías. Entales casos, se 
necesita volver a escribir la frase. 
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Uno a uno (1 :1)—Una ocurrencia [de un objeto] «A» 
se puede relacionar a una y sólo una ocurrencia del 
objeto «B», y una ocurrencia de «B» se puede rela- 
cionar sólo con una ocurrencia de «A», 


Uno a muchos (1:N)—Una ocurrencia del objeto«A» 
se puede relacionar a una o muchas ocurrencias del 
objeto «B», pero una de «B» se puede relacionar sólo 
a una ocurrencia de «A», Por ejemplo, una madre 
puede tener muchos hijos, pero un hijo sólo puede 
tener una madre. 


Muchos a muchos (M:N)—Una ocurrencia del objeto 
«A» puede relacionarse con una o más ocurrencias 
de «B», mientras que una de «B» se puede relacio- 
nar con una o más de «A», Por ejemplo, un tío puede 
tener muchos sobrinos, mientras que un sobrino 
puede tener muchos tíos. 


La cardinalidad define «el número máximo de rela- 
ciones de objetos que pueden participar en una relación» 
[TIL93]. Sinembargo,no proporcionauna indicación de 
si un objeto de datos en particular debe o no participar 
en la relación. Para especificar esta información, el mode- 
lo de datos añade modalidad a la pareja objeto-relación. 

Modalidad. La modalidad de una relación es cero 
si no hay una necesidad explícita de que ocurra una rela- 
ción, o que sea opcional. La modalidad es 1 si una ocu- 
rrencia de la relación es obligatoria. Para ilustrarlo, 
consideremos el software que utiliza una compañíatele- 
fónica local para procesar peticiones de reparación. Un 
cliente indica que hay un problema. Si se diagnostica 
que un problema es relativamente simple, sólo ocurre 
una única acción de reparación. Sin embargo, sivel pro- 
blema es complejo, se pueden requerir múltiples accio- 
nes de reparación. La Figura 12.5 ilustra la relación, 
cardinalidad y modalidad entre los objetos de datos 
cliente y acción de reparación. 


Cardinalidad: 
Implica que un solo 
cliente espere acción(es) 
de reparación 


Cardinalidad: 
Implica que puede haber 
muchas acciones 
de reparación 


Se proporciona con Acción de 


reparación 


Cliente 


Modalidad: Opcional 
Implica que puede haber 
una situación en la que 
una acción de reparación 
no sea necesaria 


Modalidad: Obligatoria 
Implica que para tener 
acción(es) de reparación, 
debemos tener 
un cliente 


FIGURA 12.5. Cardinalidad y modalidad. 
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a 
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. Tipo dig 
¡9 
so] veto, us ni 


FIGURA 12.6. Un DER y una tabla de objetos de datos simples 
(Nota: En este DER la relación «construye» 
se indica mediante un rombo sobre la línea 
de conexión entre los objetos de datos). 


En la figura, se establece una relación de cardinali- 
dad de 1 a muchos. Esto es, se puede proporcionar un 
sólo cliente con cero o muchas acciones de reparación. 
Los símbolos sobre la conexión de relación que está 
más cerca de los rectángulos del objeto de datos indica 
cardinalidad. La barra vertical indica 1, y la que está 
dividida en tres indica muchas. La modalidad se indica 
por los símbolos más lejanos de los rectángulos de obje- 
tos de datos. La segunda barra vertical a la izquierda 
indica que debe haber un cliente para que ocurra una 
acción de reparación. El círculo de la derecha indica 
que puede no existir acción de reparación para el tipo 
de problema informado por el usuario. 


12.3.3. Diagramas Entidad-Relación 


La pareja objeto-relación (estudiadaen la Sección 12.3.1) 
es la piedra angular del modelo de datos. Estas parejas se 
pueden representar gráficamente mediante el diagrama 
entidad relación (DER).El DER fue propuesto original- 
mente por Peter Chen [CHE77] para el diseño de siste- 
mas de bases de datos relacionales y ha sido ampliado por 
otros. Se identifica un conjunto de componentes prima- 
rios para el DER: objetos de datos, atributos, relaciones 
y varios indicadores tipo. El propósito primario del DER 
es representar objetos de datos y sus relaciones. 


KO 
E 


Bobjetivo principal de un DER es representar entidades 
(objetos de datas) y sus relacionesentre sí. 


Una notación DER rudimentaria se ha presentado en 
la Sección 12.3.Los objetos de datos son representados 
por un rectángulo etiquetado. Las relaciones se indican 
mediante una línea etiquetada conectando objetos. En 
algunas variaciones del DER, la línea de conexión con- 
tiene un rombo que se etiqueta con la relación. Las cone- 
xiones entre objetos de datos y relaciones se establecen 
mediante una variedad de símbolos especiales que indi- 
can cardinalidad y modalidad (Sección 12.3.2). 
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Referencia Web 


Un detallado estudio que describelos diagramas entidad 


relación puede encontrarse en www.univ-paris1.fr / 
CRINFO /dmrg/MEE/misop003/ 


La relación entre los objetos de datos coche y fabri- 
cante se representarían como se muestra en la Figura 
12.6. Un fabricante construye uno O muchos coches. 
Dado el contexto implicado por el DER, la especifica- 
ción del objeto de datos coche (consulte la tabla de obje- 
tos de datos de la Figura 12.6) sería radicalmente 
diferente de la primera especificación (Fig. 12.3) Exa- 
minando los símbolos al final de la línea de conexión 
entre objetos, se puede ver que la modalidad de ambas 
incidencias es obligatoria (las líneas verticales). 


Distribuidor Almacena 


Fabricante 


g Transportista 


FIGURA 12.7. DER ampliado. 


Ampliando el modelo, representamos un DER extre- 
madamente simplificado (Figura 12.7) del elementode 
distribución del negocio de los automóviles. Se han 
introducido nuevos objetos de datos, transportista y 
distribuidor. Además, las relaciones nuevas —trans- 
porta, contrata, autoriza y almacena — indican cómo 
los objetos de datos de la figura se asocian entre sí. Las 
tablas para cada objeto de datos del DER, se tendría que 
desarrollar de acuerdo con las reglas presentadas al 
comienzo del capítulo. 

Además de la notación de DER básica introducida 
en las Figuras 12.6 y 12.7, el analista puede represen- 
tarjerarquías de tipos de objetos de datos. En muchas 
ocurrencias, un objeto de datos realmente puede repre- 
sentar una clase o categoría de información. Por ejem- 
plo, el objeto de datos coche puede categorizarse como 
doméstico, europeo o asiático. La notación del DER 
mostrada en la Figura 12.8 representa esta categoriza- 
ción en forma de jerarquía. 
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Cons 


Desarrolle el DER deforma iterativa poro ir refinando 
los objetos de datas y los relaciones que los conectan. 


La notación del DER también proporciona un meca- 
nismo que representa la asociabilidad entre objetos. Un 
objeto de datos asociativo se representa como se mues- 
tra en la Figura 12.9. En la figura, los objetos de datos 
que modelan los subsistemas individuales se asocian 
con el objeto de datos coche. 

El modelado de datos y el diagrama entidad relación 
proporcionan al analista una notación concisa para exa- 
minar datos dentro del contexto de una aplicación de 
procesamiento de datos. En la mayoría de los casos, el 
enfoque del modelado de datos se utiliza para crear una 
parte del modelo de análisis, pero también se puede uti- 
lizar para el diseño de bases de datos y para soportar 
cualquier otro método de análisis de requisitos. 


La información se transforma a medida que fluye por un 
sistema basado en computadora. El sistema acepta entra- 
das en una gran variedad de formas; aplica elementos de 
hardware, software y humanos para transformar la entra- 
da en salida, y produce salida en una gran variedad de 
formas. La entrada puede ser una señal de control trans- 
mitida por un controlador, una serie de números escri- 
tos por un enlace de una red o un archivo voluminoso 
de datos recuperado de un almacenamiento secundario. 
La transformación puede ser, desde una sencilla com- 
paración lógica, hasta un complejo algoritmo numérico 
o un mecanismo de reglas de inferencia de un sistema 
experto. La salida puede ser el encendido de un diodo 
de emisión de luz (LED) o un informe de 200 páginas. 
Efectivamente, podemos crear un modelo de flujo para 
cualquier sistema de computadora, independientemen- 
te del tamaño y de la complejidad. 


Electrónica 


Tren de 
conducción 


Chasis 


Interior 


FIGURA 12.9. Asociación de objetos de datos. 
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Datos 
intermedios 


Información 
Entidad | de entrada 
externa 


Datos 
intermedios 


Proceso 
n2 
Entrada en 


almacenamiento 


Almacenamiento] 


FIGURA 12.10. Modelo del flujo de información. 


Entidad 
externa 


Información 
de salida 


Proceso 
n24 


Información 
de entrada 


Entidad 
externa 


Información 
de salida 


almacenamiento 


Entidad 
externa 


El análisis estructurado es una técnica del modela- 
do del flujo y del contenido de la información. Tal como 
muestra la Figura 12.10, el sistema basado en compu- 
tadora se representa como una transformación de infor- 
mación. Se utiliza un rectángulo para representar una 
entidad externa, esto es, un elemento del sistema (por 
ejemplo, un elemento hardware, una persona, otro pro- 
grama) u otro sistema que produce información para ser 
transformada por el software, o recibe información pro- 
ducida por el software. Un círculo (también llamado 
burbuja) representa un proceso o transformación que 
es aplicado a los datos (o al control) y los modifica. Una 
flecha representa uno o más elementos de datos (obje- 
tos de dato). Toda flecha en un diagrama de flujos de 
datos debe estar etiquetada. Las líneas en paralelo repre- 
sentan un almacenamiento — información almacenada 
que es utilizada por el software —. La simplicidad de la 
notación del DFD es una razón por la que las técnicas 
del análisis estructurado son ampliamente utilizadas. 


www.elsolucionario.net 


INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRACTICO 


Consuo fp 


El DED no es procedimental. No permite representar 
consu notacióngráfica tratamientos condicionales 
ni bucles. Simplementemuestro el flujo de datos. 


Es conveniente hacer notar que el diagrama no pro- 
porciona ninguna indicación explícita de la secuencia 
de procesamiento O de una condición lógica. El proce- 
dimiento O secuencia puede estar implícitamente en el 
diagrama, pues los detalles lógicos son generalmente 
retrasados hasta el diseño del software. Es importante 
no confundir un DED con el diagrama de flujo. 


12.4.1. Diagramas de flujo de datos 


A medida que la información se mueve a través del soft- 
ware, es modificada por una serie de transformaciones. 
El diagrama de flujo de datos (DF D)es una técnica que 
representa el flujo de la información y las transforma- 
ciones que se aplican a los datos al moverse desde la 
entrada hasta la salida. En la Figura 12.10 se muestra 
la forma básica de un diagrama de flujo de datos. El 
DFD es también conocido como grafo de flujo de datos 
o como diagrama de burbujas. 


a VE 


El DFD facilita un mecanismo paro modelizar el flujo 
de informacióny modelizar las funciones. 


Se puede usar el diagrama de flujo de datos para 
representar un sistema o un software a cualquier nivel 
de abstracción. De hecho, los DFDs pueden ser dividi- 
dos en niveles que representen un mayor flujo de infor- 
mación y un mayor detalle funcional. Por consiguiente, 
el DFD proporciona un mecanismo para el modelado 
funcional, así como el modelado del flujo de informa- 
ción. Al hacer esto, se cumple el segundo principio de 
análisis operacional (esto es, crear un modelo funcio- 
nal) estudiado en el Capítulo 11. 

Un DFD de nivel O, también denominado modelo 

fundamental del sistema o modelo de contexto, repre- 
senta al elemento de software completo como una sola 
burbuja con datos de entrada y de salida representados 
por flechas de entrada y de salida, respectivamente. Al 
dividir el DED de nivel O para mostrar más detalles, apa- 
recen representados procesos (burbujas) y caminos de 
flujo de información adicionales. Por ejemplo, un DFD 
de nivel 1 puede contener cinco o seis burbujas con fle- 
chas interconectadas. Cada uno de los procesos repre- 
sentados en el nivel 1 es una subfunción del sistema 
general en el modelo del contexto. 


Consuof) 


lo descomposición de un nivel de DFD en su siguiente 
debería seguir uno oproximociónal ratio] :5, reduciendo 
los futuros descomposiciones 
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Como ya indicamos anteriormente, se puede refinar 
cada una de las burbujas en distintos niveles para mos- 
trar un mayor detalle. La Figura 12.11 ilustra este con- 
cepto. El modelo fundamental del sistema F' muestra la 
entrada principal A y la salida final B. Refinamos el 
modelo F en las transformaciones f! a f7. Observe que 
se debe mantener la continuidad del flujo de informa- 
ción, es decir, que la entrada y la salida de cada refina- 
miento debe ser la misma. Este concepto, a veces 
denominado balanceo, es esencial para el desarrollo de 
modelos consistentes. Un mayor refinamiento de f4 
muestra más detalle en la forma de las transformacio- 
nes 441 a f45. De nuevo, la entrada (X, Y) y la salida 
(Z) permanecen inalteradas. 


OO E 


ere? 


FIGURA 12.11.Refinamiento del flujo de información. 


La notación básica que se usa para desarrollarun DED 
no es en sí misma suficiente para describir los requisi- 
tos del software. Por ejemplo, una flecha de un DFD 
representa un objeto de datos que entra o sale de un pro- 
ceso. Un almacén de datos representa alguna colección 
organizada de datos. Pero ¿cuál es el contenido de los 
datos implicados en las flechas o en el almacén? Si la 
flecha (o el almacén) representan una colección de obje- 
tos, jcuáles son? Para responder a estas preguntas, apli- 
camos otro componente de la notación básica del análisis 
estructurado —el diccionario de datos —. El formato y 
el uso del diccionario de datos se explica más adelante. 


Cons) 


Si bien lo continuidaddel flujo de información debe 

ser mantenido, reconocemosque un elemento de datos 
representado en un nivel puede ser refinado en sus partes 
constituyentesen el siguiente nivel. 


La notación gráfica debe ser ampliada con texto des- 
criptivo. Se puede usar una especificación de proceso 
(EP) para especificar los detalles de procesamiento que - 
implica una burbuja del DFD. La especificación de pro- 
ceso describe la entrada a la función, el algoritmo que ' 
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se aplica para transformar la entrada y la salida que se 
produce. Además, el EP indica las restricciones y limi- 
taciones impuestas al proceso (función), las caracterís- 
ticas de rendimiento que son relevantes al proceso y las 
restricciones de diseño que puedan tener influencia en 
la forma de implementar el proceso. 


124.2. Ampliaciones para sistemas de tiempo real 


Muchas aplicaciones de software son dependientes del 
tiempo y procesan más información orientada al con- 
trol de datos. Un sistema de tiempo real debe inter- 
actuar con el mundo real en marcos temporales que 
vienen dados por el mundo real. El control de naves o 
de procesos de fabricación, los productos de consumo 
y la instrumentación industrial son algunas de entre 
cientos de aplicaciones del software de tiempo real. 

Para que resulte adecuado el análisis del software de 
tiempo real, se han propuesto varias ampliaciones para 
la notación básica del análisis estructurado. 


12.43. Ampliaciones de Ward y Mellor 


Ward y Mellor [WAR85] amplían la notación básica 
del análisis estructurado para que se adapte a las 
siguientes demandas impuestas por los sistemas de 
tiempo real: 


* Flujo de información que es recogido o producido 
de forma continua en el tiempo. 


» Información de control que pasa por el sistema y el 
procesamiento de control asociado. 


» Ocurrencias múltiples de la misma transformación 
que se encuentran a menudo en situaciones de mul- 
titarea. 


+ Estados del sistema y mecanismos que producen trar- 
sición de estados en el sistema. 


Entrada 
«continua» 
Salida 
«continua» 


| 


Temperatura 


supervisada lia 0M 


Monitorizar 


y ajustar Valor 
el nivel de corregido 
temperatura 


Ajuste dl 


detemperatura 


FIGURA 12.12. Flujo de datos continuo en el tiempo. 


En un porcentaje significativo de aplicaciones de 
tiempo real, el sistema debe controlar la información 
continua en el tiempo generada por algún proceso del 
mundo real. Por ejemplo, puede que se haga necesa- 
rio un sistema de control de pruebas en tiempo real 
para máquinas de turbina de gas, para que se super- 
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vise la velocidad de la turbina, la temperatura del 
combustible y varias sondas de presión, todo ello de 
forma continua. La notación del flujo de datos con- 
vencional no hace distinciones entre datos discretos 
y datos continuos en el tiempo. Una ampliación de la 
notación básica del análisis estructurado que se mues- 
tra en la Figura 12.12 proporciona un mecanismo para 
representar el flujo de datos continuo en el tiempo. 
Para representar el flujo continuo en el tiempo se usa 
la flecha de dos cabezas, mientras que el flujo de 
datos discreto se representa con una flecha de una 
sola cabeza. En la figura, se mide continuamente la 
temperatura supervisada, mientras que sólo se pro- 
porciona un valor para el ajuste de temperatura. El 
proceso de la figura produce una salida continua, 
valor corregido. 


SS 
<Y 
Pora odecuor el modelo a un sistema en tiempo real, 


la notación del análisis estructurado debe permitir 
procesar eventos y la llegada de continuos datos. 


La distinción entre flujo de datos discreto y con- 
tinuo en el tiempo tiene implicaciones importantes, 
tanto para el ingeniero de sistemas como para el dise- 
ñador del software. Durante la creación del modelo 
del sistema, podrá aislar los procesos que pueden ser 
críticos para el rendimiento (es muy usual que la 
entrada y salida de datos continuos en el tiempo 
dependan del rendimiento). Al crear el modelo físi- 
co o de implementación, el diseñador debe estable- 
cer un mecanismo para la recolección de datos 
continuos en el tiempo. Obviamente, el sistema digi- 
tal recolecta datos en una forma casi continua utili- 
zando técnicas de muestreo de alta velocidad. La 
notación indica dónde se necesita hardware de con- 
versión analógica a digital y qué transformaciones 
requerirán, con mayor probabilidad, un software de 
alto rendimiento. 

En los diagramas de flujo de datos convenciona- 
les no se representa explícitamente el control o flu- 
jos de sucesos. De hecho, al analista se le advierte 
de que ha de excluir específicamente la representa- 
ción del flujo de control del diagrama de flujo de 
datos. Esta exclusión es demasiado restrictiva cuan- 
do se trata de aplicaciones de tiempo real y, por este 
motivo, se ha desarrollado una notación especiali- 
zada para la representación del flujo de sucesos y del 
procesamiento de control. Siguiendo con los conve- 
nios establecidos para los diagramas de flujo de 
datos, el flujo de datos se representa mediante fle- 
chas con trazo continuo. Sin embargo, el flujo de 
control se representa mediante flechas de trazo dis- 
continuo O sombreadas. Un proceso que sólo mane- 
ja flujos de control denominadoproceso de control, 
se representa analógicamente mediante una burbuja 
con trazo discontinuo. 
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Movimiento 
» Estado de Cana 
X.. cada elemento ecos 7 
A E : 
Buffer del estado y Control de 
de las piezas Indicador de , actividad 
<> comienzo/parada za del robot 
y Ns 


Cadena de bits' 


Y 


Interfaz 


del monitor 
de instalación 


y operación 


1 ; 

y Activar 
t proceso 
1 


Órdenes 
del operador 


Ajustes 
del operador 


Registro de movimientos 
del robot e 
Archivo de Órdenes 
del robot 
FIGURA 12.13. Flujos de datos y de control utilizando 
la notación de Ward y Mellor [WAR85]. 


Procesar 
órdenes 
del robot 


El flujo de control puede ser una entrada directa de 
un proceso convencional o de un proceso de control. La 
Figura 12.13 ilustra el flujo de control y su procesa- 
miento, utilizando la notación de Ward y Mellor. La 
figura ilustra el planteamiento de mayor nivel de un flu- 
jo de datos y de control de una célula de fabricación. A 
medida que se van colocando en las fijaciones los com- 
ponentes a ser ensamblados por un robot, se ajusta un 
bit de un buffer de estado de las piezas (un almacén 
de control) que indica la presencia O ausencia de cada 
componente. La información de sucesos contenida en 
el buffer de estado de las piezas se pasa como una 
cadena de bits a un proceso, interfaz del monitor de 

fijación y operador. El proceso leerá Ordenes del ope- 
rador sólo cuando la información de control, cadena 
de bits, indique que todas las fijaciones contienen com- 
ponentes. Se envía un indicador de suceso, indicador 
de comienzo/parada, a control de activación del robot, 
un proceso de control que permite un posterior proce- 
samiento de órdenes. Como consecuencia del suceso 
activar proceso se producen otros flujos de datos que 
son enviados aprocesar órdenes del robot. 


“un sistema en tiempo real a veces 
dispositivos que octúon como los 5 sentidos 


y Stephen Mellor 


En algunas situaciones, en un sistema de tiempo real 
puede haber ocurrencias múltiples del mismo proceso 
de control o de transformación de datos. Se puede dar 
este caso en un entorno multitarea en el que se activan 
las tareas como resultado de algún procesamiento inter- 
no O de sucesos externos. 
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Por ejemplo, puede que haya que supervisar varios 
buffers de estado de piezas para que puedan activarse 
diferentes robots en los momentos oportunos. Además, 
puede que cadarobot tenga su propio sistema de control. 
La notación de Ward y Mellor se usa para representar 
múltiples ocurrencias equivalentes del mismo proceso. 


12.4,.4. Ampliaciones de Hatley y Pirbhai 


Las ampliaciones de Hatley y Pirbhai [HAT87] a la 
notación básica del análisis estructurado se centra menos 
en la creación de símbolos gráficos adicionales y más en 
la representación y especificaciónde los aspectos del soft- 
ware orientados al control. La flecha de trazo discontinuo 
se utiliza para representar el flujo de control o de sucesos. 
A diferencia de Ward y Mellor, Hatley y Pirbhai sugieren 
que serepresente por separado la notación de trazo conti- 
nuo de la de trazo discontinuo. Así, se define un diagra- 
ma de flujo de control (DFC).El DFC contiene los mismos 
procesos que el DFD, pero muestra el flujo de control en 
lugar de datos. En lugar de representar directamente los 
procesos de control dentro del modelo de flujo, se usa una 
referencia de notación (una barra sólida) a una especifica- 
ción de control (EC).En esencia, se puede considerar la 
barra como una «ventana»hacia un «director»(la EC) que 
controla los procesos (las burbujas) representadas en el 
DFD, de acuerdo con los sucesos que pasan a través de la 
ventana. Se usa la EC, que se describe en detalle en la Sec- 
ción 12.6.4,para indicar: (1) cómo se comportael software 
cuando se detecta un suceso o una señal de control, y (2) 
qué procesos se invocan como consecuencia de la ocu- 
rrencia del suceso. Se usa una especificación de proceso 
(EP )para describir el procesamiento interno de los proce- 
sos representados en el diagrama de flujo. 


a 


CLAVE 


El DFC muestra como los eventos se mueven 

en el sistema. Una EC muestra el comportamiento 
del software como una consecuenciade los eventos 
y a qué procesos les corresponde intervenir 

en la manipulación de los eventos. 


Usando la notación descrita en las Figuras 12.12 y 
12.13,junto con la información adicional contenida en 
EPs y ECs, Hatley y Pirbhai crean un modelo de siste- 
ma de tiempo real. Para representar los datos y los pro- 
cesos que los manejan se usan los diagramas de flujo de 
datos. Los diagramas de flujo de control muestran cómo 
fluyen los sucesos entre los distintos procesos e ilustran 
cómo los sucesos externos hacen que se activen los pro- 
cesos. Las interrelaciones entre los modelos de proce- 
so de control se muestran esquemáticamente en la Figura 
12.14. El modelo de procesamiento está «conectado»con 
el modelo de control a través de condiciones de datos. 
El modelo de control está «conectado» con el modelo 
de procesos mediante la información de activación de 
procesos contenida en la EC. 
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Referencia 


la especificación del sema en tiempo real planteada 
por Hatley y Pirbhaies descrita en www.univ-paris l.fr 
/CRINFO/dmrg/MEE98/misop032/ 


Una condición de datos se produce cuando los datos 
de entrada de un proceso hacen que se produzca una sali- 
da de control. La Figura 12.14 ilustra esta situación en una 
parte del modelo de flujo para un sistema de supervisión 
y control automatizado de válvulas de presión de una refi- 
nería de petróleo. El proceso comprobary convertirpre- 
sión implementael algoritmo descrito en el pseudocódigo 
EP que se muestra. Cuando la presión absoluta del tanque 
es mayor que el máximo permitido, se genera un suceso 
presión alta. Observe que cuando se usa la notación de 
Hatley y Pirbhai, el flujo de datos de muestra como par- 
te deun DFD, mientras que el flujo de control se encuen- 
tra a parte en un diagrama de flujo de control. 


Diagrama Diagrama 
de flujo de datos de flujo de control 
Presión absoluta Presión 


del tanque convertida Comprobar 
y convertir | Presión 
presión alta 


Comprobar 
y convertir 
presión 


Presión ye 


máxima 


EP 


end 
endif 
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Para determinar qué es lo que ocurre cuando se pro- 
duce este suceso, debemos comprobar la EC. 

La especificación de control (EC) contiene varias 
herramientas importantes del modelado. Para indicar 
qué procesos se activan por un suceso dado que flu- 
ye por la barra vertical, se usa una tabla de activa- 
ción de procesos (descrita en la Sección 12.6.4). Por 
ejemplo, una tabla de activación de procesos (TAP) 
para la Figura 12.14 podría indicar que el suceso pre- 
sión alta haría que se invocara un proceso reducir 
presión del tanque (que no se muestra). Además de 
la TAP, la EC puede contener un diagrama de tran- 
sición de estados (DTE).El DTE es un modelo de 
comportamiento que se basa en la definición de un 
conjunto de estados del sistema y se describe en la 
sección siguiente. 


Estado 
de alimentación 
del papel 
(atascado. vacío) 
Ss Alarma 


Comienzo/ / 
parada / 
Z 


Producir 
visualización 
de usuario 


Gestión 
de copilado 


Leer 
entrada de 
operador 


Realizar 
diagnóstico 
del 
problema 


Recargar 
papel Llena 


E Ñ 
Fallo 


de reproducción 


FIGURA 12.15. DFC de nivel 1 para el software de una foto- 
copiadora. 


El modelado del comportamiento es uno de los prin- 
cipios fundamentales de todos los métodos de análi- 
sis de requisitos. Sin embargo, sólo algunas versiones 
ampliadas del análisis estructurado ([WAR85], 
[HAT871) proporcionan una notación para este tipo 
de modelado. El diagrama de transición de estados 
representa el comportamiento 'de un sistema que 
muestra los estados y los sucesos que hacen que el 
sistema cambie de estado. Además, el DTE indica 
qué acciones (por ejemplo, activación de procesos) 
se llevan a cabo como consecuencia de un suceso 
determinado. 
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$ ¿Cómo modelizar la reacción 
del software ante un evento 
externo? 


Un estadoes un modo observable de comportamiento. 
Por ejemplo, estados para un sistema de supervisión y de 
control para que las válvulas de presión descritas en la Sec- 
ción 1244. puedan estar en: estado de supervisión, esta- 
do de alarma, estadode liberación depresión y otros. Cada 
uno de estos estados representa un modo de comporta- 
miento del sistema. Un diagrama de transición de estados 
indica cómo se mueve el sistema de un estado a otro. 
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Para ilustrar el uso de las ampliaciones de compor- 
tamiento y de control de Hatley y Pirbhai, consideremos 
el software empotrado en una máquina fotocopiadorade 
oficina. En la Figura 12.15 se muestra un flujo de con- 
trol para el software de fotocopiadora. Las flechas del 
flujo de datos se han sombreado ligeramente con pro- 
pósitos ilustrativos, pero en realidad se muestran como 
parte de un diagrama de flujo de control. 

Los flujos de control se muestran de cada proceso 
individual y las barras verticales representan las «ven- 
tanas» EC. Por ejemplo, los sucesos estado de al;- 
mentación del papel y de comienzo/parada fluyen 
dentro de la barra de EC. Esto implica que cada uno 
de estos sucesos hará que se active algún proceso 
representado en el DFC. Si se fueran a examinar las 
interioridades del EC, se mostraría el suceso comien- 


Leyendo 
órdenes 


Copias hechas 


invocar leer-op-ent 


j Inactiva 
Llena y comienzo invocar Teer-op-ent 


invocar gestión de copiado 


Llena 
invocar leer-op-ent 


Ea 
aloa 
Rabal 


No atascado 
invocar leer-op-ent 


En 


Vacía 


invocar Ea pap 
' 
Atascada 


invocar realizar diagnóstico del problema 


Diagnosticando 
el problema 


FIGURA 12.16. Diagramas de transición de estados simplifi- 
cado para el software de una fotocopiadora. 


zo/parada para activar/desactivar el proceso de ges- 
tión de copiado. De forma similar, el suceso atasca- 
da (parte del estado de alimentación del papel) 
activaría realizar diagnóstico del problema. Se debe- 
ría destacar que todas las barras verticales dentro del 
DFC se refieren a la misma EC. Un flujo de suceso 
se puede introducir directamente en el proceso como 
muestra fallo de reproducción. Sin embargo, este flw- 
jo no activa el proceso, sino que proporciona infor- 
mación de control para el algoritmo de proceso. 

Un diagrama de transición de estados simplificado 
para el software de fotocopiadora descrito anterior- 
mente se muestra en la Figura 12.16. Los rectángulos 
representan estados del sistema y las flechas repre- 
sentan transiciones entre estados. Cada flecha está eti- 
quetada con una expresión en forma de fracción. La 
parte superior indica el suceso (o sucesos) que hace(n) 
que se produzca la transición. La parte inferior indica 
la acción que se produce como consecuencia del suce- 
so. Así, cuando la bandeja de papel está llena, y el 
botón de comienzo ha sido pulsado, el sistema pasa 
del estado leyendo órdenes al estado realizando copias. 
Observe que los estados no se corresponden necesa- 
riamente con los procesos de forma biunívoca. Por 
ejemplo, el estado realizando copias englobaría tanto 
el proceso gestión de copiado como el proceso pro- 
ducir visualización de usuario que aparecen en la Figu- 
ra 12.15. 


z 
. 
erdido es un estado de confusión. 
ca misteriosa sobre un DTE 


En la sección anterior, hemos visto las notaciones 
básica y ampliada del análisis estructurado. Para 
poder utilizarlas eficientemente en el análisis de 
requisitos del software, se ha de combinar esa nota- 
ción con un conjunto de heurísticas que permitan al 
ingeniero del software derivar un buen modelo de 
análisis. Para ilustrar el uso de esas heurísticas, en el 
resto de este capítulo utilizaremos una versión adap- 
tada de las ampliaciones de Hatley y Pirbhai [HAT87] 
a la notación básica del análisis estructurado. 


Corso) 


El modelo de análisis permite un exóme.. crítico 

de los requisitosde/sofware desde tres puntos 
diferentes de vista. Asegurando la utilidad de los DERS, 
DEDs y DTEs cuando construyesel modelo 


En las secciones siguientes, se examina cada uno 
de los pasos que se debe seguir para desarrollar mode- 


los completos y precisos mediante el análisis estruc- 
turado. A lo largo de este estudio, se usará la notación 
presentada en la Sección 12.4 y se presentarán, con 
algún detalle, otras formas de notación ya aludidas 
anteriormente. 


12.6.1. Creación de un diagrama Entidad-Relación 


El diagrama de entidad-relación permite que un ingeniero 
del software especifique los objetos de datos que entran y 
salen de un sistema, los atributos que definen las propie- 
dades de estos objetos y las relaciones entre los objetos.Al 
igual que la mayoría de los elementos del modelo de aná- 
lisis y las relaciones entre objetos, el DER se construye de 
una forma iterativa. Se toma el enfoque siguiente: 


Ed ¿Cuáles son los pasos 
requeridos para construir 


un DER? 
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1. Durante la recopilación de requisitos, se pide que los 
clientes listen las «cosas» que afronta el proceso de 
la aplicación o del negocio. Estas «cosas» evolu- 
cionan en una lista de objetos de datos de entrada y 
de salida, así como entidades externas que producen 
o consumen información. 


. Tomando objetos uno cada vez, el analista y el cliente 

definen si existe una conexión (sin nombrar en ese 

punto) o no entre el objeto de datos y otros objetos. 

Siempre que existe una conexión, el analista y el 

cliente crean una o varias parejas de objeto-relación. 

. Para cada pareja objeto-relación se explóra la cardi- 
nalidad y la modalidad. 

. Interactivamente se continúan los pasos del 2 al 4 
hasta que se hayan definido todas las parejas objeto- 
relación. Es normal descubrir omisiones a medida 
que el proceso continúa. Objetos y relaciones nue- 
vos se añadirán invariablemente a medida que crezca 
el número de interacciones. 

. Se definen los atributos de cada entidad. 

Se formaliza y se revisa el diagrama entidad-relación. 


JA 


. Se repiten los pasos del 1 al 7 hasta que se termina 
el modelado de datos. 


Para ilustrar el uso de estas directrices básicas, usa- 
remos el ejemplo del sistema de seguridad HogarSe- 
guro tratado en el Capítulo 11. A continuación, 
reproducimos la narrativa de procesamiento para Hogar- 
Seguro (Sección 11.3.3), la siguiente lista (parcial) de 
«cosas» son importantes para el problema: 


* propietario 

* panel de control 

* sensores 

e sistema de seguridad 
* servicio de vigilancia 


Propietario 


Panel 


Sensor 
de control 


Servicio 
de vigilancia 


Sistema 
de seguridad 


FIGURA 12.17. Establecimiento de conexiones. 


Tomando estas «cosas» una a una, se exploran las 
conexiones. Para realizar esto, se dibuja cada objeto y 
se señalan las líneas que conectan objetos. Por ejemplo, 
la Figura 12.17 muestra que existe una conexión direc- 
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ta entre el propietario y panel de control, sistema de 
seguridad y servicio de vigilancia. Existe una cone- 
xión Única entre el sensor y el sistema de seguridad, y 
así sucesivamente. 

Una vez que se han definido todas las conexiones, 
se identifican una o varias parejas objeto-relación para 
cada conexión. Por ejemplo, se determina la conexión 
entre sensor y sistema de seguridad para que tenga las 
parejas objeto-relación siguientes: 

el sistema de seguridad supervisa el sensor 

el sistema de seguridad activaldesactiva el sensor 

el sistema de seguridad prueba el sensor 

el sistema de seguridad programa el sensor 

Cada una de las parejas objeto-relación anteriores se 
analizan para determinar la cardinalidad y la modali- 
dad. Por ejemplo, en la pareja objeto-relación el siste- 
ma de seguridad supervisa el sensor, la cardinalidad 
entre sistema de seguridad y sensor es una a muchos. 
La modalidad es una incidencia de sistema de seguri- 
dad (obligatoria) y al menos una incidencia de sensor 
(obligatorio). Mediante la notación DER introducidaen 
la Sección 12.3, la línea de conexión entre sistema de 
seguridad y sensor se modificaría, como se muestra en 
la Figura 12.18. Se aplicaría un análisis similar al res- 
to de los objetos de datos. 


Supervisa 


Activa/desactiva 


Sistema de 
Prueba 


seguridad 


[ 


FIGURA 12.18. Desarrollo de relaciones y cardinalidad/ 
modalidad. 


Programa 


Se estudia cada objeto para determinar sus atributos. 
Como se está considerando el software que debe sopor- 
tar HogarSeguro, los atributos se deberían centrar en 
datos que deban almacenarse para permitir que opere el 
sistema. Por ejemplo, el objeto sensor podría tener los 
atributos siguientes: tipo de sensor, número de identifi- 
cación interna, localización de zona, y nivel de alarma. 


126.2. Creación de un modelo de flujo de datos 


El diagrama de flujo de datos (DFD )permite al inge- 
niero del software desarrollar los modelos del ámbito 
de información y del ámbito funcional al mismo tiem- 
po. A medida que se refina el DFD en mayores niveles 
de detalle, el analista lleva a cabo implícitamente una 
descomposición funcional del sistema. Al mismo tiem- 
po, el refinamiento del DFD produce un refinamiento 
de los datos a medida que se mueven a través de los pro- 
cesos que componen la aplicación. 


www.elsolucionario.net 


INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRACTICO 


¿Existe alguna guía útil para 
crear DFD's? 


Unas pocas directrices sencillas pueden ayudar de 
forma considerable durante la derivación de un diagra- 
ma de flujo de datos; (1) el diagrama de flujo de datos 
de nivel O debe reflejar el software/sistema como una 
sola burbuja; (2) se deben anotar cuidadosamente la 
entrada y la salida principales; (3 Jel refinamiento debe 
comenzar aislando los procesos, los objetos de datos y 
los almacenes de datos que sean candidatos a serrepre- 
sentados en el siguiente nivel; (4)todas las flechas y las 
burbujas deben ser rotuladas con nombres significati- 
vos; (5 Jentre sucesivos niveles se debe mantener la con- 
tinuidad del flujo de información; (6)se deben refinar 
las burbujas de una en una. Hay una tendencia natural 
a complicar en exceso el diagrama de flujo de datos. 
Esto ocurre cuando el analista intenta reflejar demasia- 
dos detalles demasiado pronto o representa aspectos 
procedimentales en detrimento del flujo de información. 

En la Figura 12.19se muestra el DED de nivel O para 
HogarSeguro. Las entidades externas principales (cua- 
dros) producen información para ser usada por el siste- 
ma y consumen información generada por el sistema. 
Las flechas etiquetadas representan objetos de datos u 
objetos de datos de tipojerárquico. Por ejemplo, órde- 
nes y datos de usuario engloba todas las Órdenes de 
configuración, todas las Órdenes de activación/desacti- 
vación, todas las variadas interacciones y todos los datos 
que se introducen para cualificar o ampliar una orden. 


Monitor 
del panel 


Información 
para visualizar 


Órdenes 
y datos de usuario 


Panel 
de control 


HogarSeguro 


Estado 
del sensor 


Sensores del número 


de teléfono 
FIGURA 12.19.DFD de nivel contextual para HogarSeguro. 


Ahora tenemos que expandir el DED de nivel O o de 
nivel a un modelo de nivel 1, Pero, ¿cómo lo hacemos? 
Una sencilla, pero efectiva, técnica consiste en realizar un 
«análisisgramatical»de la narrativa de procesamiento que 
describe la burbuja de nivel contextual. Es decir, aislar 
todos los nombres (y sentencias nominales) y todos los 
verbos (y sentencias verbales) de la narrativa presentada 
arriba. Para ilustrarlo, reproducimos de nuevo la narrati- 
va de procesamiento, subrayando las primeras ocurren- 
cias de los nombres y con las primeras ocurrencias de los 
verbos en cursiva. (Se debería señalar que se omiten los 
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nombres y los verbos que son sinónimos y no se apoyan 
directamenteen el proceso de modelado). 


Cionsuo 


El análisisgramotical no es seguro, pero facilito 
una excelenteplataforma siestás empezando 
a definir objetas de datos y su transformación. 


El software HogarSeguro permite al propietario de la 
vivienda configurar el sistema de seguridad al instalarlo; 
supervisa todos los sensores conectados al sistema de segu- 
ridad e interactúa con el propietario a través de un teclado 
numérico y unas teclas de función que se encuentran en el 
panel de control de HogarSeguro que se muestra en la Figu- 
ra 11.2, 


Durante la instalación, se usa el panel de control de Hogar- 
Seguro para «programar» y configurarel sistema. Cada sen- 
sor tiene asignado un número y un tipo, existe una contraseña 
maestra para activar y desactivar el sistema, y se introdu- 
ce(n)un(os) teléfono(s) con los que contactar cuando se pro- 
duce un suceso detectado por un sensor. 


Cuando el software detecta un suceso, invoca una alar- 
ma audible que está incorporada en el sistema. Tras un retar- 
do, especificado por el propietario durante la configuración 
del sistema, el programa marca un número de teléfono de un 
servicio de monitorización, proporciona información sobre 
la situación e informa sobre la naturaleza del suceso detec- 
tado. Cada 20 segundos se volverá a marcar el número de 
teléfono hasta que se consiga establecer la comunicación. 


Toda la interacción con HogarSeguro está gestionada par 
un subsistema de interacción con el usuario que lee la infor- 
mación introducida a través del teclado numérico y de las 
teclas de función, muestra mensaies de petición en un moni- 
tor LCD y muestra información sobre el estado del sistema 
en el monitor LCD. La interacción por teclado toma la 
siguiente forma... 


De acuerdo con el «análisis gramatical», comienza 
a aparecer un patrón. Todos los verbos son procesos 
de HogarSeguro, es decir, deben estar en última ins- 
tancia representados como burbujas en el consiguien- 
te DFD. Todos los nombres son, o bien entidades 
externas (cuadrados), objetos de datos o de control 
(flechas) o almacenes de datos (líneas dobles). Ade- 
más los nombres y los verbos están relacionados entre 
sí (por ejemplo, cada sensor tiene asignado un núme- 
ro y un tipo). Por tanto, con el análisis gramatical de 
la narrativa de procesamiento de una burbuja de cual- 
quier nivel de DFD, podemos generar mucha infor- 
mación útil sobre cómo proceder en el refinamiento 
del siguiente nivel. Usando esa información, obtene- 
mos el DEFD de nivel 1 que se muestra en la Figura 
12.20.El proceso de nivel contextual de la Figura 12.19 
se ha expandido en siete procesos, derivados de un 
examen del análisis gramatical. De forma similar se 
ha derivado el flujo de información entre los procesos 
del nivel 1. 


3 Se debe tener en cuenta que serán omitidos los nombres y verbos 
que sean sinónimos o no tengan una relación directa con el modelo 
de procesos. 
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mensajes 


Procesar la 
contraseña 


Contraseña 
válida 


Datos de 
configuración 


Información 
del sensor 


Monitorizar 
sensores 


Tonos del número 
de teléfono 


Estado 
del sensor 


FIGURA 12.20. DFD de nivel 1 para HogarSeguro. 


- 


Se debe tener en cuenta que entre los niveles O y 1 
se ha mantenido la continuidad del flujo de informa- 
ción. Se pospone hasta la Sección 12.7 la elaboración 
de los contenidos de las entradas y las salidas de los 
DED de niveles O y 1. 


RonsuoH 


Escierto que el proceso narrativopretende analizar 
lo escrito siempre con el mismo nivel de abstracción. 


Se pueden refinar en posteriores niveles los proce- 
sos representados en el DFD de nivel 1. Por ejemplo, 
se puede refinar el proceso monitorizar sensores al DFD 
de nivel 2 que se muestra en la Figura 12.21.Podemos 
observar de nuevo que se mantiene la continuidad del 
flujo de información entre los niveles. 

El refinamientode los DFDs continúa hasta que cada 
burbuja representa una función sencilla. 


Informamión del sensor 


Dar formato . 
Tipo 
de alarma 


Información de configuración visualización 


Generar 
señal 
de alarma 


Identificación 


Datos 


, ss Datos 
de configuración 


de alarma 


Comprobar 
con los valores 
iniciales Número 
de teléfono 


Tipo de id. 


de sensor 
Marcar 


número 


a 


stado del sensor Tonos del número de teléfono 


FIGURA 12.21. DFD de nivel 2 que refina el proceso 
monitorizar sensores. 
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12.6.3. Creación de un modelo de flujo de control 


Para muchos tipos de aplicaciones de procesamiento de 
datos, todo lo que se necesita para obtener una represen- 
tación significativa de los requisitos del software es el 
modelo de flujo de datos. Sin embargo, como ya hemos 
mencionado anteriormente, existe una clase de numero- 
sas aplicaciones que están «dirigidas»por sucesosen lugar 
de por los datos, que producen información de control más 
que informes o visualizaciones, que procesan informa- 
ción con fuertes limitaciones de tiempo y rendimiento. 
Tales aplicaciones requieren un modelado del flujo de con- 
trol además del modelado del flujo de información. 

La notación gráfica que se requiere para crear un dia- 
grama de flujo de control (DFC)ya ha sido presentada 
en la Sección 12.4.4. Recordando la forma en que se 
crea un DFC, lo primero es «eliminar» del modelo de 
flujo de datos todas las flechas de flujo de datos. Lue- 
go, se añaden al diagrama los sucesos y los elementos 
de control (flechas con línea discontinua), así como 
«ventanas» (barras verticales) a las especificaciones de 
control. Pero, ¿cómo se seleccionan los sucesos? 


Panel 
deRamáto! 


e indicador de Estado de la acción 
parpadeo de visualización 
ee +| seminosa en marcha) 
mn "> 
Pd 
Pe 


Configurar 


el sistema 


— 
> — 


A N 
77 Interruptor 2 


de comienzo/parada ] / 
Y 
cl 


>. Ñ / 
Activar/ 

desactivar 

el sistema 


Interactuar 


Intrcrhar 
USA? 


=> 
Y 


/ 


Visualizar 
mensajes 


Procesar la 
contraseña 


Señal 
de alarma 
a 


Suceso 
de sensor 


+) 
a 
Sensores 


FIGURA 12.22. DFDde nivell para HogarSeguro. 


/, 


Monitorizar 
sensores 


A 


o Línea 


telefónica 


Ya hemos señalado que los sucesos o los elementos 
de control se implementan como valores lógicos (por 
ejemplo, verdadero ofalso, sio no, 1 Ó0)o como una 
lista discreta de condiciones (vacía, atascada, llena). 
Para seleccionar posibles candidatos a sucesos, se pue- 
den sugerir las siguientes directrices: 

Listar todos los sensores que son «leídos» por el soft- 
ware. 

Listar todas las condiciones de interrupción. 

Listar todos los «interruptores» que son accionados 
por el operador. 

Listar todas las condiciones de datos. 

De acuerdo con el análisis de nombres y verbos que 
se aplicó a la narrativa de procesamiento, revisar 
todos los «elementos de control» como posibles 
entradas/salidas de ECs, 
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Describir el comportamiento del sistema identifi- 
cando sus estados; identificar cómo se alcanza cada 
estado y definir las transiciones entre los estados. 
Centrarse en las posibles omisiones —un error muy 
común en la especificación del control (por ejemplo, 
preguntarse si existe alguna otra forma en la que se 
puede llegar a un estado o salir de é)— 


Cómo seleccionaseventos 
= potenciales para DFC, DTE y EC? 


En la Figura 12.22se ilustra un DFC de nivel 1 para el 
software HogarSeguro. Entre los sucesos y los elementos 
de controlque aparecen están suceso de sensor (por ejem- 
plo, un sensor ha detectado una anomalía), indicador de 
parpadeo (una señal para que el monitor LCD parpadee), 
e interruptor de comienzo/parada (una señal para encen- 
der y apagar el sistema). Un suceso fluye a una ventana 
EC desde el mundo exterior, ello implica la activaciónpor 
la EC de uno o más procesos de los que aparecen en el 
DFC. Cuando un elemento de control emana de un pro- 
ceso y fluye a una ventana EC, ello implica el control y la 
activación de algún proceso o de una entidad externa. 


Interruptor de comienzo/parada 
Invocar monitor y control 
del sistema 


Leyendo 
entrada 
del usuario 


Exceso de tiempo 


Invotarinteractuar 
con el usuario 


Suceso de sensor 
Invocar monitorizar 


y controlar el sistema 


Monitorización Actuando 
del estado sobre un suceso 
del sistema Suceso de sensor de sensor 

> Invocar visualizar mensaje 
y estado 


Suceso de sensor 
Invocar visualizar 
mensaje y estado 


Suceso de sensor 
Invocar monitorizary controlarsistema 


Mostrando 
realimentación 
al usuario 


Estado de la acción 
de visualización 


Indicador de parpadeo 


12.64. Ia especificación de control 


La especificación de control (EC) representa el com- 
portamiento del sistema (al nivel al que se ha hecho 
referencia) de dos formas diferentes. La EC contiene 
un diagrama de transición de estados (DTE)que es 
una especificación secuencial del comportamiento. 
También puede contener una tabla de activación de 
procesos (TAP) —una especificación combinatoria del 
comportamiento —. En la Sección 12.4.4.se presenta- 
ron los atributos inherentes de la EC. Ahora es el 
momento de examinar un ejemplo de esta importante 
notación del modelado del análisis estructurado. 
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La Figura 12.23 refleja un diagrama de transición de 
estados para el modelo de flujode nivel 1 de HogarSegu- 
ro. Las flechas de transición etiquetadas indican cómores- 
ponde el sistema a los sucesos a medida que pasa por los 
cuatro estados definidosen este nivel. Estudiandoel DTE, 
un ingeniero del software puede determinar el comporta- 
miento del sistema y, lo que es más importante, compro- 
bar si hay «lagunas»en el comportamiento especificado. 

Una representación algo diferente del modo de com- 
portamientoes la tabla de activación de procesos (TAP). 
La TAPrepresenta la información contenida en el DTE 
dentro del contexto de los procesos, no de los estados. 
Es decir, la tabla indica los procesos (burbujas) del 
modelo de flujo que serán invocados cuando se pro- 
duzca un suceso. Se puede usar la TAP como una guía 
para el diseñador que tenga que construir un controla- 
dor que controle los procesos representadosen ese nivel. 
En la Figura 12.24 se muestra una TAP para el modelo 
de flujo de nivel 1 de HogarSeguro. 

La EC describeel comportamientodel sistema, pero no 
nos proporciona información sobre el funcionamientointer- 
no de los procesos que son activados como resultado de ese 
comportamiento. En la siguiente sección se estudia la nota- 
ción del modelado que proporciona esa información. 


12.6.5. La especificación del proceso 


Se usa la especificación de proceso (EP) para describir 
todos los procesos del modelo de flujo que aparecen en 
el nivel final de refinamiento. El contenido de la espe- 
cificación de procesamiento puede incluir una narrati- 
va textual, una descripción en lenguaje de diseño de 
programas (LDP)del algoritmo del proceso, ecuacio- 
nes matemáticas, tablas, diagramas o gráficos. Al pro- 
porcionar una EP que acompañe cada burbuja del 
modelo de flujo, el ingeniero del software crea una 
«mini-especificación» que sirve como primer paso para 
la creación de la Especificación de Requisitos del Soft- 
ware y constituye una guía para el diseño de la compo- 
nente de programa que implementará el proceso. 


Sucesos de entrada 


Suceso de sensor 
Indicador de parpadeo 
Interruptor de comienzo/parada 
Estado de la acción de visualización 
Terminada 
En marcha 
Exceso de tiempo 


ooo ooo 


Salida 
Señal de alarma 


Activación de procesos 


Monitorizarycontrolar el sistema 
Activar/desactivar el sistema 
Visualizar mensajes y estado 
Interactuar con el usuario 


FIGURA 12.24. Tabla de activación de procesos para 
HogarSeguro. 
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Para ilustrar el uso de la EP consideremos el proce- 
so que representa la transformación del modelo de flu- 
jo de Hogarseguro (Figura 12.20). La EP para esta 
función puede tomar la siguiente forma: 


EP: proceso 


Procesar la contraseña lleva a cabo la validación de 
«todas las contraseñas del sistema HogarSeguro. Proce- 
sar la contraseña recibe una contraseña de 4 dígitos des- 
de la función interactuar con el usuario. La contraseña 
primero se compara con la contraseña maestra almace- 
nada en el sistema. Si al contrastar con la contraseña 
maestra, <contraseña validada = true> se pasa a la fun- 
ción visualizar mensajes y estado. Si la comparación no 
es correcta, los cuatro dígitos se comparan con una lis- 
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ta secundaria de contraseñas (estas pueden asignarse a 
invitados o trabajadores que necesitan entrar en la casa 
cuando el propietario no está presente). Si la contraseña 
coincide con alguna de las de la lista, <contraseña vali- 
dada =true> es pasada a la función visualizar mensajes 
y estado. Si no existe coincidencia, <contraseña valida- 
da = false> se pasa a la función visualizar mensajes y 
estado. 


Si en esta etapa se desea incluir detalles algorít- 
micos adicionales, se puede incluir como parte de la 
EP su representación en lenguaje de descripción de 
programa. Sinembargo, muchos piensan que se debe 
posponer la versión en LDP hasta que comience el 
diseño. 


El modelo de análisis acompaña representaciones de 
objetos de datos, funciones y control. En cada repre- 
sentación los objetos de datos y/o elementos de control 
juegan un papel importante. Por consiguiente, es nece- 
sario proporcionar un enfoque organizado para repre- 
sentar las características de cada objeto de datos y 
elemento de control. Esto se realiza con el diccionario 
de datos. 

Se ha propuesto el diccionario de datos como gra- 
mática casi formal para describir el contenido de los 
objetos definidos durante el análisis estructurado. Esta 
importante notación de modelado ha sido definida de la 
siguiente forma [YOUS9]: 


El diccionario de datos es un listado organizado de todos 
los elementos de datos que son pertinentes para el sistema, con 
definiciones precisas y rigurosas que permiten que el usuario 
y el analista del sistema tengan una misma comprensión de las 
entradas, salidas,de las componentes de los almacenes y [tam- 
bién] de los cálculos intermedios. 


Cómo representar 

el contenido de los objetos 
de datos que han sido 
identificados? 


Actualmente, casi siempre se implementa el dic- 
cionario de datos como parte de una «herramienta 
CASE de análisis y diseño estructurados». Aunque 
el formato del diccionario varía entre las distintas 
herramientas, la mayoría contiene la siguiente infor- 
mación: 

* nombre——<l nombre principal del elemento de datos 
o de control, del almacén de datos, o de una entidad 
externa. 
alias — otros nombres usados para la primera 
entrada. 


* dónde se usa/cómo se usa—un listado de los proce- 
sos que usan el elemento de datos o de control y 
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cómo lo usan (por ejemplo, como entrada al proceso, 
como salida del proceso, como almacén de datos, 
como entidad externa). 


Descripción del contenido—el contenido represen- 
tado mediante una notación. 


. Información adicional-otra información sobre los 
tipos de datos, los valores implícitos (si se conocen), 
las restricciones O limitaciones, etc. 


Una vez que se introducen en el diccionario de 
datos un nombre y sus alias, se debe revisar la con- 
sistencia de las denominaciones. Es decir, si un equi- 
po de análisis decide denominar un elemento de datos 
recién derivado como xyz, pero en el diccionario ya 
existe otro llamado xyz, la herramienta CASE que 
soporta el diccionario muestra un mensaje de alerta 
sobre la duplicidad de nombres. Esto mejora la con- 
sistencia del modelo de análisis y ayuda a reducir 
errores. 

La información de «dónde se usa/cómo se usa» se 
registra automáticamente a partir de los modelos de 
flujo. Cuando se crea una entrada del diccionario, la 
herramienta CASE inspecciona los DFD y los DFC 
para determinar los procesos que usan el dato o la 
información de control y cómo lo usan. Aunque esto 
pueda no parecer importante, realmente es una de las 
mayores ventajas del diccionario. Durante el análi- 
sis, hay una corriente casi continua de cambios. Para 
proyectos grandes, a menudo es bastante difícil deter- 
minar el impacto de un cambio. Algunas de las pre- 
guntas que se plantea el ingeniero del software son 
«¿dónde se usa este elemento de datos? ¿qué mas hay 
que cambiar si lo modificamos? ¿cuál será el impac- 
to general del cambio?». Al poder tratar el dicciona- 
rio de datos como una base de datos, el analista puede 
hacer preguntas basadas en «dónde se usa/cómo se 
usan y obtener respuestas a peticiones similares a las 
anteriores. 
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Para ilustrar el uso del diccionario de datos, volva- 
mos al DED de nivel 2 y del proceso monitorizar el sis- 
tema de HogarSeguro, mostrado en la Figura 12.21. 
Refiriéndonos a la figura, especificamos el elemento de 


Herramientas CASE datos número de teléfono. ¿Qué es exactamente un 

Análisis Estructurado número de teléfono? Puede ser un número local de sie- 

. o . te dígitos, una extensión de 4 dígitos, o una secuencia 

_ La notación utilizada para desarrollar una descrip- de 25 dígitos para llamadas de larga distancia. El dic- 
ción de contenido se indica en la siguiente tabla: cionario de datos nos proporciona una definición pre- 


» 5 A cisa de número de teléfono para el DFD en cuestión. 

Construcción Notación Significado a ae z A 

de dat Además, indica dónde y cómo se usa este elemento de 
Suatos datos y cualquier información adicional que le sea rele- 

Agregación _ está compuesto de vante. La entrada del diccionario de datos comienza de 

la siguiente forma: 


Secuencia + Y 
Selección [1] uno u otro nombre: número de teléfono 
entes " Dd alias: ninguno 
Repetición 11 n repeticiones de pl E E , dni 
dónde se usalcómo se usa: comprobar con ajustes inicia- 
O datos opcionales les (salida) 
* a E 
dE delimitadores marcar número (entrada) 
de comentarios descripción: 


número de teléfono = prefijo + número de acceso 


La notación permite al ingeniero del software repre- pieñjo=[ din aúmeto de cuatro dititos que comienosón 


sentar una composición de datos en una de las tres alter- 0 Ó un número de cinco dígitos que comience por 0] 

nativas fundamentales que pueden ser construidas número de acceso = *secuencianumérica de cualquiertama- 

1. Como una secuencia de elementos de datos. ño* 

2. Como una selección de entre un conjunto de ele- Un número como el 01327 546381 queda descrito 
mentos de datos. de esta forma. 

3. Como una agrupación repetitivade elementos de datos. Para grandes sistemas basados en computadora el 


Cada entrada de elemento de datos que aparezca como diccionario de datos crece rápidamente en tamaño y en 
parte de una secuencia, una selección o una repetición complejidad. De hecho, es extremadamente difícil marr 
puede a su vez ser otro elementode datoscompuestos tener manualmente el diccionario. Por esta razón, se 
que necesite un mayor refinamiento en el diccionario. deben usar herramientas CASE. 


Durante los últimos años se han utilizado otros méto- +» Técnicas de análisis y diseño estructurado (TADE) 
dos valiosos de análisis de requisitos del software en la [ROS77, ROS85] 

industria. Mientras que todos siguen los principios del son presentadas dentro del sitio web SEPA para los lecto- 
análisis operacional tratados en el Capítulo11, cada uno res interesadosen profundizar en el modelado del análisis. 
introduce una notación y heurística diferentespara cons- 
truir el modelo de análisis. Una revisión de tres impor- 
tantes métodos de análisis: 


meca 


» Desarrollo de sistemas estructurados de datos 
(DSED)[WAR81, ORR81] 
. Desarrollo de sistemas Jackson (DSJ)[JAC83] DSSD, ISD, y SADT 


lA AC ne ono: 


" ML AA ca 


El análisis estructurado es el método más usado parael de todos los objetos de datos que son importantes para 
modelado de requisitos, utiliza el modelo de datos y el el sistema. Los sistemas de datos y flujo de control son 
modelo de flujos para crear la base de un adecuado la base de representación de la transformación de datos 
modelo de análisis. Utilizando el diagrama entidad-rela- y control. Al mismo tiempo, estos métodos son usados 
ción, el ingeniero del software crea una representación para crear un modelo funcional del software y proveer- 
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se de un mecanismo para dividir funciones. Después, 
brea un modelo de comportamiento usando el diagra- 
iña de transición de estados y un modelo de contenido 
de los datos con un diccionario de datos. Las especifi- 
caciones de los procesos y del control proporcionan una 
elaboración adicional de los detalles. 

La notación original para el análisis estructurado 
fue desarrollada para aplicaciones de procesamiento 


(BRU88] Bruyn, W. et al., «ESML: An Extended Systems 
Modeling Language Based on the Data Flow Diagram», 
ACM Software Engineering Notes, vol. 13, n.” 1, Enero 
1988, pp. 58-67. 

[CHE77] Chen, P., The Entity-Relationship Approach to Logi- 
cal Database Design, QED Information systems, 1977. 
[DEM79] DeMarco, T., Structured Analysis and System Spe- 

, Cificaction, Prentice-Hall, 1979. 


[GAN82] Gane, T., y C, Sarson, Structured Systems Analy- 
sis, McDonnell Douglas, 1982. 

[HAT87] Hatley, D.J., e LA. Pirbhai, Strategies for Real- 
Time System Specification, Dorset House, 1987. 

[JAC83] Jackson, M.A., System Development, Prentice-Hall, 
1983. 


[ORR81] Orr, K.T., Structured Requirements Definition, Ken 
Orr £ Associates, Inc., Topeka, KS, 1981. 


[PAG80] Page-Jones, M., The Practical Guide to Structured 
Systems Design, Yourdon Press, 1980. 
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de datos convencionales, pero ahora hay ampliacio- 
nes que permiten aplicar el método a los sistemas de 
tiempo real. 

El análisis estructurado está soportado por una 
larga lista de herramientas CASE que ayudan en la 
creación de cada elemento del modelo y también 
en el mantenimiento de la consistencia y de la 
corrección. 
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[ROS77] Ross, D., y K. Schoman, «Structured Analysis for 
Requirements Definitions», [EEE Trans. Software Engi- 
neering, vol. 3, n." 1, Enero 1977, pp. 6-15. 


[ROS84] Ross, D., «Applications and Extensions of SADT», 
IEEE Computer, vol. 18,n.* 4, Abril 1984, pp. 25-35. 


[STE74] Stevens, W.P., G.J. Myers y L.L. Constantine, 
«Structured Design», IBM Systems Journal, vol. 13,n.? 2, 
1974,pp. 115-139. 


[TIL93] Tillman, G.A., A Practical Guide to Logical Data 
Modeling, McGraw-Hill, 1993. 


[WAR81] Warnier, J.D., Logical Construction of Programs, 
Van Nostrand Reinhold, 1981, 


[WAR85] Ward, P.T., y S.J. Mellor, Structured Development 
for Real-TimeSystems, tres volúmenes, Yourdon Press, 1985. 


[YOU78] Yourdon, E.N., y L.L. Constantine, Structured 
Design, Yourdon Press, 1978. 


[YOUS9] Yourdon, E.N., Modern Structured Analysis, Pren- 
tice Hall, 1990. 


121. Obtenga al menos tres de las diferencias que se men- 
cionan en la sección 12.1 y escriba un breve artículo que 
refleje el cambio a lo largo del tiempo de la concepción 
del análisis estructurado. En una sección de conclusiones, 
Sugiera formas en las que crea que cambiará el método en 
el futuro. 


122. Se le pide que construya uno de los sistemas siguientes: 


a un sistemade registro en cursos basado en red para su uni- 


versidad 


. un sistema procesamiento de transacciones basado en inter- 
net para un almacén de computadoras 


. Un sistema simple de facturas para una empresa pequeña 


o 


un producto de software que sustituya a rolodex construi- 
do en un teléfono inalámbrico 
. Un producto de libro de cocina automatizado construido en 
una cocina eléctrica O en un microondas 
Seleccione el sistema que le sea de interés y desarrolle un 
diagrama entidad-relación que describa los objetos de datos, 
relaciones y atributos. 


123. ¿Qué diferencia hay entre cardinalidad y modalidad? 
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12.4. Dibuje un modelo de nivel de contexto (DFD de nivel 
0) para uno de los cinco sistemas que se listan en el problema 
12.2. Escriba una descripción de procesamiento a nivel de con- 
texto para el sistema. 


12.5. Mediante el DED de nivel de contexto desarrollado en 
el problema 12.4, desarrolle diagramas de flujo de datos de 
nivel 1 y nivel 2. Utilice un «analizador gramatical» en la des- 
cripción de procesamiento a nivel de contexto para que se ini- 
cie en ese tema. Recuerde especificar todo el flujo de 
información etiquetando todas las flechas entre burbujas. Uti- 
lice nombres significativos para cada transformación. 


12.6. Desarrolle DFC, EC, EP y un diccionario de datos para 
el sistema que seleccionó en el problema 12.2. Intente cons- 
truir su modelo tan completo como sea posible. 


12.7. ¿Significa el concepto de continuidad del flujo de infor- 
mación que si una flecha de flujo aparece como entrada en el 
nivel O, entonces en los subsiguientes niveles debe aparecer 
una flecha de flujo como entrada? Explique su respuesta. 


12.8. Usando las ampliaciones de Ward y Mellor descritas en 
las figuras 12.13.¿Cómo encaja la EC que se indica en la figu- 
ra 12,13? Ward y Mellor no usan esa notación. 
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12.9. Usando las ampliaciones de Hatley y Pirbhai, rehaga el 
modelo de flujo contenido en la Figura 12.13. ¿Cómo encaja 
el modelo de control que se indica en la Figura 12.13? Hatley 
y Pirbhai no usan esa notación. 


12.10. Describa con sus propias palabras un flujo de sucesos. 


12.11. Desarrolle un modelo de flujo completo para el soft- 
ware de fotocopiadora discutido en la sección 12.5.Puede uti- 
lizar las ampliaciones de Ward y Mellor o las de Hatley y 
Pirbhai. Asegúrese de desarrollar para el sistema un diagrama 
de transición de estados detallado. 


12.12. Complete la descripción de procesamiento para el soft- 
ware HogarSeguro que se ha presentado en la Figura 12.20; 
describiendo los mecanismo de interacción entre el usuario y 
el sistema. ¿Cambiará su información adicional los modelos 
de flujo de HogarSeguro que aparecen en este capítulo? Sies 
así, ¿cómo? 


12.13. El departamento de obras públicas de un gran ciudad 
ha decidido desarrollar un sistema de seguimiento y repara- 
ción de baches (SSRB Jbasado en página web. Con los siguien- 
tes requisitos: 

Los ciudadanos pueden conectarse a la página e infor- 
mar sobre la situación y la importancia del bache. A medi- 
da que se informa sobre cada bache, se le asigna un número 
de identificación y se guarda con la calle en la que se 
encuentra, su tamaño (en una escala de l a 10), su posi- 
ción (en el medio, a un lado, etc.), su distrito (determina- 
do a partir de la calle) y una prioridad de reparación 


Existen literalmente docenas de libros publicados sobre el aná- 
lisis estructurado. Todos cubren el tema de forma adecuada, 
pero sólounos pocos constituyen magníficos trabajos. El libro 
de DeMarco [DEM79] sigue siendo una buena introducción 
de la notación básica. Los libros de Hoffer et al. (Modern Sys- 
temsAnalysis and Design, Addison-Wesley,2.* ed., 1998), Ken- 
dall y Kendall (Systems Analysis and Design, 2.* ed., Prentice 
Hall,1998), Davis y Yen (TheInformation System Consultant's 
Handbook: Systems Analysis and Design, CRCPress,1998), 
Modell (AProfessional's Cuide to Systems Analysis, 2." ed., 
McGraw-Hill, 1996), Robertson and Robertson (Complete S ys- 
tems Analysis, 2 vols., Dorset House, 1994), y Page-Jones(The 
Practical Cuide to Structured Systems Design, 2.* ed., Prenti- 
ce Hall, 1988) son referencias muy valiosas. El libro de Your- 
don sobre este tema [YO0U89] sigue siendo el tratado más 
extenso publicado hasta la fecha. 

Para mayor énfasis en la ingeniería, [WAR85] y [HAT87] 
son los libros preferidos. En cualquier caso, Edwards (Real- 
Time Structured Methods: SystemsAnalysis, Wiley, 1993) tra- 
ta el análisis de sistemas en tiempo real con gran profundidad, 
presentando diagramas de ejemplos Útiles sobre aplicaciones 
reales. 

Se han desarrollado muchas variaciones sobre el análisis 
estructuradodurantela última década. Cutts (StructuredSystems 
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(determinada a partir de su tamaño). A cada bache se le 
asocian datos de petición de obra, incluyendo la ubicación 
y el tamaño, la brigada, el equipamiento asignado, las horas 
de reparación, el estado del bache (obra en curso, reparag 
do, reparación temporal, no reparado), la cantidad de mate, 
rial de relleno usado y el coste de la reparación (calculaéz 
con las horas dedicadas, el número de trabajadores, el mate- 
rial y el equipamientousados). Finalmente, se crea un archi- 
vo de daños para mantener la información sobre los daños 
reportados debidos a la existencia del bache, incluyendo 
el nombre del ciudadano, su dirección, su número detelé. 
fono, el tipo de daño y el coste de subsanamiento del dia 
El sistema SSRB es un sistema interactivo. 


Utilice el análisis estructurado para modelar SSRB. 


12.14. Se va a desarrollar un sistema de procesamientode tex- 
tos basados en computadoras personales. Investigue durantealgu- 
nas horas sobre el área de aplicación y lleve a cabo una reunión 
TFEA (Capítulo 11)con sus compañeros de clase para un mode- 
lo de requisitos del sistemautilizandoel análisis estructurado (su 
profesor le ayudaráa coordinarlo).Construyaun modelo de requí- 
sitos del sistema mediante el análisis estructurado. 


12.15. Se va a desarrollar el software para un videojuego. Pro- 
ceda como en el problema 12.14. 


12.16.Contacte con cuatro o cinco vendedores de herramien- 
tas CASE para análisisestructurado. Revise sus folletos y escri- 
ba un breve artículo que resuma las características generales 
y las que se distingan a unas herramientas de las otras. 


Analysis and Design Methodology, Van Nostrand Reinhlod, 
1990) y Hares (SSADMfor the Advanced Pructitioner, Wiky, 
1990) describe SSADM como una variación del análisis 
estructurado que se utiliza enormemente por toda Europa y 
Estados Unidos. 

Elynn etal. (Information Modelling: An International Pers: 
pective, Prentice Hall, 1996), Reingruber y Gregory (Data 
Modeling Handbook, Wiley, 1995) y Tillman [TIL93] pre- 
sentan manuales detallados para crear modelos de datos de 
calidad de industria. Kim y Salvatores («Comparing Data 
Modeling Formalisms», Communications of the ACM, June 
1995) han escrito una comparación excelente de métodos de 
modelado de datos. Un libro interesante de Hay (DataMode- 
ling Patterns, Dorset House, 1995) presenta los «patronest 
comunes de modelos de datos que se encuentran en mucha 
empresas diferentes. En Kowal (Behaviour Models: Speci- 
fying User's Expectations, Prentice-Hall, 1992) se puede 
encontrar un tratamiento detallado del modelado de compor- 
tamiento. 

Una amplía variedad de fuentes de información sobre 
el análisis estructurado están disponibles en internet. Una 
lista actualizada de páginas web que son interesantes sobre 
el concepto y métodos de análisis se encuentran en 
http://www.pressman5.com 
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CAPÍTULO 


13 


CONCEPTOS Y PRINCIPIOS 
DE DISEÑO 


L objetivo de los diseñadores es producir un modelo o representación de una entidad que 
se será construida a posteriori. Belady describe el proceso mediante el cual se desarro- 
lla el modelo de diseño [BEL3]1]: 


En cualquier proceso de diseño existen dos fases importantes: la diversificación y la convergencia. La 
diversificación es la adquisición de un repertorio de alternativas, de un material primitivo de diseño: com- 
ponentes, soluciones de componentes y conocimiento, todo dentro de catálogos, de libros de texto y en la 
mente. Durante la convergencia, el diseñador elige y combina los elementos adecuados y extraídos de este 
repertorio para satisfacer los objetivos del diseño, de la misma manera a como se establece en el documento 
de los requisitos, y de la manera en que se acordó con el cliente. La segunda fase es la eliminación gradual 
de cualquier configuración de componentes excepto de una en particular, y de aquí la creación del producto 
final. 


La diversificación y la convergencia combinan intuición y juicio en función de la experien- 
cia en construir entidades similares; un conjunto de principios y/o heurística que proporcionan 
la forma de guiar la evolución del modelo; un conjunto de criterios que posibilitan la calidad 
que se va ajuzgar, y un proceso de iteración que por Último conduce a una representación final 
de diseño. 


VISTAZO RÁPIDO 


*. ¿Qué es? El diseño es una representación 
significativa de ingeniería de algo que 
se va a construir. Se puede hacer el 
“seguimiento basándose en los requisi- 

tos del cliente, y al mismo tiempo la cali- 
: dad se puede evaluar y cotejar con el 
conjunto de criterios predefinidos para 
: obtener un diseño «bueno». En el con- 
: «texto de la ingeniería del software, el 
" diseño se centra en cuatro áreas impor- 
tantes de interés: datos, arquitectura, 
interlaces y componentes. En estas cua- 
“tro áreas se aplican los principios y con- 
.ceptos que se abarcan.en este capítulo 


¿Quién lo hace? El ingeniero del soft- 
ware es quien diseña los sistemas 
basados en computadora, pero los 
' ¿conocimientos que se requieren en 
«cada nivel de diseño funcionan de dife- 


de arquitectura, el diseño se centra en 
. los patrones de la misma manera a 


. rentes maneras. En el nivel de datos y - 


como se aplican en la aplicación que 
se va a construir. En el nivel de la inter- 
faz, es la ergonómica humana la que 
dicta nuestro enfoque de diseño. Y en 
el nivel de componentes, un «enfoque 
de programación» conduce a diseños 
de datos y procedimentales eficaces. 
¿Por qué es importante? Si se cons- 
truye una casa, ¿se hace sin un plano? 
Se correrian riesgos, se cometerían 
errores, habría un plano de casa sin 
sentido, con ventanas y puertas en 


sitios equivocados... un desastre. El : 


software de computadora 'es conside- 
rablemente más complejo que una 


casa, de aquí que necesitemos ún pla-: 


no —el diseño—, 
¿Cuáles son los pasos? El diseño 


comienza con el modelo de los requi- 
sitos. Se trabaja por transformar este 


modelo y obtener cuatro niveles de.. 
detalles de diseño: la estructura en 


datos, la arquitectura del sistema, la 
representación de la interfaz y los deta," 
lles a nivel de componentes. Durante 
cada una de las actividades del dise-- 


ño, se ap! ¿los conceptos y princi- 
pios cos que llevan a obtener una 
alta calidad. 


¿Cuál es el producto obtenido? Por 
último se produce una especificación 
del diseño, La especificación se com- 
pone de los modelos del diseño que 
describen los datos, arquitectura, inter- 
faces y componentes. Cada una de 
estas partes es lo que forma el produc- 
to obtenido del proceso de diseño, 

¿Cómo puedo estar seguro de que lo 
he hecho correctamente? En cada 
etapa se revisan los productos del dise- 

.ño del software en cuanto a claridad, 
corrección, finalización y consistencia, 
; y se comparan con eme 


E e con otros. 


El diseño del software, al igual que los a de diseño de ingeniería en otras discipli- 
nas, va cambiando continuamente a medida que se desarrollan métodos nuevos, análisis mejo- 
res y se amplia el conocimiento. Las metodologías de diseño del software carecen de la 
profundidad, flexibilidad y naturaleza cuantitativa que se asocian normalmente a las discipli- 
nas de diseño de ingeniería más clásicas. Sin embargo, sí existen métodos para el diseño del 
software; también se dispone de calidad de diseño y se pueden aplicar notaciones de diseño. 
En este capítulo se explorarán los conceptos y principios fundamentales que se pueden aplicar 
a todo diseño de software. En los Capítulos 14, 15, 16 y 22 se examinan diversos métodos de 
diseño de software en cuanto a la manera en que se aplican al diseño arquitectónico, de inter- 
faz y anivel de componentes. 
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INGENIERÍA DEL SOFTWARE. UN ENFUQUE PKAUILICU 


El diseño del software se encuentra en el núcleo técni- 
co de la ingeniería del software y se aplica indepen- 
dientemente del modelo de diseño de software que se 
utilice. Una vez que se analizan y especifican los requi- 
sitos del software, el diseño del software es la primera 
de las tres actividades técnicas — diseño, generación de 
código y pruebas — que se requieren para construir y 
verificar el software. Cada actividad transforma la infor- 
mación de manera que dé lugar por último a un soft- 
ware de computadora validado. 


comunes de la ingeniería 
los transiciones desde el análisis 
e el diseño al código. 


Cada uno de los elementos del modelo de análi- 
sis (Capítulo 12) proporciona la información nece- 
saria para crear los cuatro modelos de diseño que se 
requieren para una especificación completa de dise- 
ño. El flujo de información durante el diseño del soft- 
ware se muestra en la Figura 13.1. Los requisitos del 
software, manifestados por los modelos de datos fun- 
cionales y de comportamiento, alimentan la tarea del 
diseño. Mediante uno de los muchos métodos de dise- 
ño (que se abarcarán en capítulos posteriores) la tarea 
de diseño produce un diseño de datos, un diseño 
arquitectónico, un diseño de interfaz y un diseño de 
componentes. 

El diseño de datos transforma el modelo del domi- 
nio de información que se crea durante el análisis en las 
estructuras de datos que se necesitarán para implemen- 
tar el software. Los objetos de datos y las relaciones 
definidas en el diagrama relación entidad y el conteni- 
do de datos detallado que se representa en el dicciona- 
rio de datos proporcionan la base de la actividad del 
diseño de datos. Es posible que parte del diseño de datos 
tenga lugar junto con el diseño de la arquitectura del 
software. A medida que se van diseñando cada uno de 
los componentes del software, van apareciendo más 
detalles de diseño. 

El diseño arquitectónico define la relación entre 
los elementos estructurales” principales del software, 
los patrones de diseño que se pueden utilizar para 
lograr los requisitos que se han definido para el sis- 
tema, y las restricciones que afectan a la manera en 
que se pueden aplicar los patrones de diseño arqui- 
tectónicos [SHA96]. La representación del diseño 
arquitectónico —el marco de trabajo de un sistema 
basado en computadora — puede derivarse de la espe- 
cificación del sistema, del modelo de análisis y de la 
interacción del subsistema definido dentro del mode- 
lo de análisis. 
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El modelo 
de análisis 


El modelo de diseño 


FIGURA 13.1. Conversión del modelo de análisis 
en un diseño de software. 


El diseño de la interfaz describe la manera de 
comunicarse el software dentro de sí mismo, con sis- 
temas que interoperan dentro de él y con las personas 
que lo utilizan. Una interfaz implica un flujo de infor- 
mación (por ejemplo, datos y/o control) y un tipo espe- 
cífico de comportamiento. Por tanto, los diagramas 
de flujo de control y de datos proporcionan gran par- 
te de la información que se requiere para el diseño de 
la interfaz. 

El diseno a nivel de componentes transforma los ele- 
mentos estructurales de la arquitectura del softwareen 
una descripción procedimental de los componentes del 
software. La información que se obtiene de EP, EC y 
de DTE sirve como base para el diseño de los compo- 
nentes. 

La importancia del diseño del software se puede 
describir con una sola palabra —calidad—. El dise- 
ño es el lugar en donde se fomentará la calidad en la 
ingeniería del software. El diseño proporciona las 
representaciones del software que se pueden evaluar 
en cuanto a calidad. El diseño es la única forma de 
convertir exactamente los requisitos de un cliente en 
un producto o sistema de software finalizado. El dise- 
ño del software sirve como fundamento para todos los 
pasos siguientes del soporte del software y de la inge- 
niería del software. Sin un diseño, corremos el ries- 
go de construir un sistema inestable —un sistema que 
fallará cuando se lleven a cabo cambios; un sistema 
que puede resultar difícil de comprobar; y un sistema 
cuya calidad no puede evaluarse hasta muy avanzado 
el proceso, sin tiempo suficiente y con mucho dinero 
gastado en él— 
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ucuiuEPTOS Y PRINCIPIOS DE DISEÑO 


UNTIAYANS 1 


El diseño del software es un proceso iterativo mediante 
el cual los requisitos se traducen en un «plano» para cons- 
truir el software. Inicialmente, el plano representa una 
visión holística del software. Esto es, el diseño se repre- 
senta a un nivel alto de abstracción —un nivel que puede 
rastrearse directamente hasta conseguirel objetivo del sis- 
tema específico y según unos requisitos más detallados 
de comportamiento, funcionales y de datos —. A medida 
que ocurren las iteraciones del diseño, el refinamiento 
subsiguiente conduce a representacionesde diseño a nive- 
les de abstracción mucho más bajos. Estos niveles se 
podrán rastrear aún según los requisitos, pero la conexión 


es más sutil. 


13,2,1. Diseño y calidad del software 


A lo largo de todo el proceso del diseño, la calidad de 
la evolución del diseño se evalúa con una serie de revi- 
siones técnicas formales o con las revisiones de diseño 
abordadas en el Capítulo 8. McGlaughlin [MCG91] 
sugiere tres características que sirven como guía para 
la evaluación de un buen diseño: 

el diseño deberá implementar todos los requisitos 
explícitos del modelo de análisis, y deberán ajustarse 
atodos los requisitos implícitos que desea el cliente; 
el diseño deberá ser una guía legible y comprensible 
para aquellos que generan código y para aquellos que 
comprueban y consecuentemente, dan soporte al soft- 
ware; 

el diseño deberá proporcionar una imagen completa 
del software, enfrentándose a los dominios de com- 
portamiento, funcionales y de datos desde una pers- 
pectiva de implementación. 


buen diseño, hay que pensar 
correcto de llevar a cobo lo actividad 


Con el fin de evaluar la calidad de una representación 
de diseño, deberán establecerse los criterios técnicos para 
un buen diseño. Más adelante en este mismo Capítulo, se 
abordarán más detalladamentelos criterios de calidad del 
diseño. Por ahora se presentarán las siguientes directrices: 
1. Un diseño deberá presentar una estructura arquitectó- 

nica que (1) se haya creado mediante patrones de diseño 

reconocibles, (2) que esté formada por componentes 
que exhiban características de buen diseño (aquellas 
que se abordarán más adelante en este mismo capítulo), 

Y (3) que se puedan implementar de manera evolutiva, 

facilitando así la implementación y la comprobación. 


2. Un diseño deberá ser modular; esto es, el software 
deberá dividirse lógicamente en elementos que rea- 
licen funciones y subfunciones específicas. 
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¿Existen directrices 
generales que lleven 


a un buen diseño? 


. Un diseño deberá contener distintas representacio- 
nes de datos, arquitectura, interfaces y componentes 
(módulos). 

Un diseño deberá conducir a estructuras de datos ade- 
cuadas para los objetos que se van a implementar y 
que procedan de patrones de datos reconocibles. 


Un diseño deberá conducir a componentes que Pre” 
senten características funcionales independientes. 


. Un diseño deberá conducir a interfaces que reduz- 
can la complejidad de las conexiones entre los módu- 
los y con el entorno externo. 


. Un diseño deberá derivarse mediante un método 'epe” 
titivo y controlado por la información obtenida 


durante el análisis de los requisitos del software. 
Estos criterios no se consiguen por casualidad. El pro- 


ceso de diseño del software fomenta el buen diseño a tra- 
vés de la aplicación de principios de diseño fundamentales, 


de metodología sistemática y de una revisión cuidadosa. 


e construir un diseño de software: 
tun diseño ton simple que no 

fe deficiencias, y la otra es hacer 
que no existan deficiencias 
forma es mucho más difícil. 


13.2.2. La evolución del diseño del software 


La evolución del diseño del software es un proceso con- 
tinuo que ha abarcado las últimas cuatro décadas. El pri- 
mer trabajo de diseño se concentraba en criterios para el 
desarrollo de programas modulares [DEN”73] y métodos 
para refinar las estructuras del software de manera des- 
cendente [WIR71]. Los aspectos procedimentales de la 


definición de diseño evolucionaron en una filosofía deno” 
minada PrOgramación estructurada [DAH71, MIL72]. 
Un trabajo posterior propuso MÉLOAOS para la conversión 
del flujo de datos [STE74] o estructura de datos [JAC7S5, 
WAR?74] en una definición de diseño, Enfoques de dise- 
ñO más recientes hacia la derivación de diseño proponen 
un método orientado a objetos. Hoy en día, se ha hecho 
hincapié en un diseño de software basado en la arquitec- 
tura del software [GAMO9S, BUS96, BROS8]. 

Independientementedel modelo de diseño que se uti- 
lice, un ingeniero del software deberá aplicar un con- 
junto de principios fundamentales y conceptos básicos 
para el diseño a nivel de componentes, de interfaz, arqui- 
tectónico y de datos. Estos principios y conceptos se 
estudian en la sección siguiente. 
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INGENIERÍA DEL SOFTWARE. U 


El diseño de software es tanto un proceso como un 
modelo. Elproceso de diseño es una secuenciade pasos 
que hacen posible que el diseñador describa todas los 
aspectos del software que se va construir. Sin embargo, 
es importante destacar que el proceso de diseño sim- 
plemente no es un recetario. Un conocimiento creativo, 
experiencia en el tema, un sentido de lo que hace que 
un software sea bueno, y un compromiso general con 
la calidad son factores críticos de éxito para un diseño 
competente. 

El modelo de diseño es el equivalente a los planes 
de un arquitecto para una casa. Comienza representan- 
do la totalidad de todo lo que se va a construir (por ejem- 
plo, una representación en tres dimensiones de la casa) 
y refina lentamentelo que va a proporcionarla guía para 
construir cada detalle (por ejemplo, el diseño de fonta- 
nería). De manera similar, el modelo de diseño que se 
crea para el softwareproporciona diversas visiones dife- 
rentes de software de computadora. 

Los principios básicos de diseño hacen posible que 
el ingeniero del software navegue por el proceso de dise- 
ño. Davis [DAV95] sugiere un conjunto" de principios 
para el diseño del software, los cuales han sido adapta- 
dos y ampliados en la lista siguiente: 


* Enelproceso de diseño no deberá utilizarse «ore- 
jeras». Un buen diseñador deberá tener en cuenta 
enfoques alternativos, juzgando todos los que se 
basan en los requisitos del problema, los recursos 
disponibles para realizar el trabajo y los conceptos 
de diseño presentados en la Sección 13.4. 


El diseño deberá poderse rastrear hasta el modelo 
de análisis. Dado que un solo elemento del modelo 
de diseño suele hacer un seguimiento de los múlti- 
ples requisitos, es necesario tener un medio de ras- 
trear cómo se han satisfecho los requisitos por el 
modelo de diseño. 

El diseño no deberá inventar nada que ya esté 
inventado. Los sistemas se construyen utilizando 
un conjunto de patrones de diseño, muchos de los 
cuales probablemente ya se han encontrado antes. 
Estos patrones deberán elegirse siempre como una 
alternativa para reinventar. Hay poco tiempo y los 
recursos son limitados. El tiempo de diseño se 
deberá invertir en la representación verdadera de 
ideas nuevas y en la integración de esos patrones 
que ya existen. 

El diseño deberá «minimizar la distancia intelec- 
tual» [DAV95] entre el software y el problema como 
side la misma vida real se tratara. Es decir, la estruc- 
tura del diseño del software (siempre que sea posi- 
ble) imita la estructura del dominio del problema. 


1 Aquí solo se destaca un pequeño subconjunto de los principios 
de diseño de Davis. Para mas información, véase [DAV95]. 
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* El diseño deberápresentar uniformidad e integración. 
Un diseño es uniforme si parece que fue una persona 
la que lo desarrolló por completo. Las reglas de estilo 
y de formato deberán definirse para un equipo de 
diseño antes de comenzar el trabajo sobre el diseño. 
Un diseño se integra si se tiene cuidado a la hora de 
definir interfaces entre los componentes del diseño. 


» El diseño deberá estructurarse para admitir cam- 
bios. Los conceptos de diseño estudiados en la sec- 
ción siguiente hacen posible un diseño que logra este 
principio. 

El diseño deberá estructurarsepara degradarsepoco 
apoco, incluso cuando se enfrenta con datos, suce- 
sos o condiciones de operación aberrantes. Un soft- 
ware bien diseñado no deberá nunca explotar como 
una «bomba». Deberá diseñarse para adaptarse a cir- 
cunstancias inusuales, y si debe terminar de funcio- 
nar, que lo haga de forma suave. 


ey VE 


Lo consistencia del diseño y lo uniformidad es crucial 
cuando se van a construir sistemas grandes. Se deber6 
establecer un conjunto de reglas de diseño para el equipo 
del software antes de comenzar a trabajar. 


» El diseño no es escribir código y escribir código no 
es diseñar. Incluso cuando se crean diseños proce- 
dimentales para componentes de programas, el nivel 
de abstracción del modelo de diseño es mayor que 
el código fuente. Las únicas decisiones de diseño 
realizadas a nivel de codificación se enfrentan con 
pequeños datos de implementación que posibilitan 
codificar el diseño procedimental. 


El diseño deberá evaluarse enfunción de la calidad 
mientras se va creando, no después de terminarlo. 
Para ayudar al diseñador en la evaluación de la cali- 
dad se dispone de conceptos de diseño (Sección 13.4) 
y de medidas de diseño (Capítulos 19 y 24). 


* El diseño deberá revisarsepara minimizar los errores 
conceptuales (semánticos).A veces existe la tenden- 
cia de centrarseen minucias cuando se revisa el diseño, 
olvidándose del bosque por culpa de los árboles. Un 
equipo de diseñadores deberá asegurarse de haber 
afrontado los elementos conceptualesprincipales antes 
de preocuparse por la sintaxis del modelo del diseño. 


Referencia cruzada 


En el Capítulo 8 se presentan los directrices pora llevar 
a cabo revisiones de diseño efectivas. 
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Cuando los principios de diseño descritos anterior- 
mente se aplican adecuadamente, el ingeniero del soft- 
ware crea un diseño que muestra los factores de calidad 
tanto internos como externos [MEY88]. Losfactores de 
calidad externos son esas propiedades del software que 
pueden ser observadas fácilmente por los usuarios (por 
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ejemplo, velocidad, fiabilidad, grado de corrección, usa- 
bilidad)?. Losfactores de calidad internos tienen impor- 
tancia para los ingenieros del software. Desde una 
perspectiva técnica conducen a un diseño de calidad alta. 
Para lograr los factores de calidad internos, el diseñador 
deberá comprender los conceptos de diseño básicos. 


Durante las últimas cuatro décadas se ha experimenta- 
do la evolución de un conjunto de conceptos funda- 
mentales de diseño de software. Aunque el grado de 
interés en cada concepto ha variado con los años, todos 
han experimentadoel paso del tiempo. Cada uno de ellos 
proporcionarán la base de donde el diseñador podrá apli- 
car los métodos de diseño más sofisticados. Cada uno 
ayudará al ingeniero del software a responder las pre- 
guntas siguientes: 

¿Qué criterios se podrán utilizar para la partición del 
software en componentes individuales? 

¿Cómo se puede separar la función y la estructura de 
datos de una representación conceptual del software? 
¿Existen criterios uniformes que definen la calidad 
técnica de un diseño de software? 


M.A. Jackson una vez dijo: «El comienzo de la sabi- 
duría para un ingeniero del softwarees reconocer la dife- 
rencia entre hacer que un programa funcione y conseguir 
que lo haga correctamente». [JAC875] Los conceptos de 
diseño de software fundamentales proporcionan el mar- 
co de trabajo necesario para conseguir q ue lo haga 
correctamente». 


as 
1 es una de los formos fundamentales 
5 se enfrentan con la 


13.41. Abstracción 


Cuando se tiene en consideración una solución modu- 
lar a cualquier problema, se pueden exponer muchos 
niveles de abstracción. En el nivel más alto de abstrac- 
ción, la solución se pone como una medida extensa 
empleando el lenguaje del entorno del problema. En 
niveles inferiores de abstracción, se toma una orienta- 
ción más procedimental. La terminología orientada a 
problemas va emparejada con la terminología orienta- 
da a la implementación en un esfuerzo por solucionar 
el problema. Finalmente, en el nivel más bajo de abs- 
tracción, se establece la solución para poder imple- 
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mentarse directamente. Wasserman [WAS83] propor- 
ciona una definición útil: 

La noción psicológica de «abstracción» permite concen- 
trarse en un problema a algún nivel de generalización sin tener 
en consideración los datos irrelevantes de bajo nivel; la utili- 
zación de la abstracción también permite trabajar con concep- 
tos y términos que son familiares en el entorno del problema 
sin tener que transformarlos en una estructura no familiar... 


Cada paso del proceso del software es un refina- 
miento en el nivel de abstracción de la solución del soft- 
ware. Durante la ingeniería del sistema, el software se 
asigna como un elemento de un sistema basado en com- 
putadora. Durante el análisis de los requisitos del soft- 
ware, la solución del software se establece en estos 
términos: «aquellos que son familiares en el entorno del 
problema». A medida que nos adentramos en el proce- 
so de diseño, se reduce el nivel de abstracción. Final- 
mente el nivel de abstracción más bajo se alcanza cuando 
se genera el código fuente. 

A medida que vamos entrando en diferentes niveles 
de abstracción, trabajamos para crear abstracciones pro- 
cedimentales y de datos. Una abstracción procedimen- 
tal es una secuencia nombrada de instrucciones que tiene 
una función específica y limitada. Un ejemplo de abs- 
tracción procedimental sería la palabra «abrir» para una 
puerta. «Abrir» implica una secuencia larga de pasos 
procedimentales (por ejemplo, llegar a la puerta; alcan- 
Zar y agarrar el pomo de la puerta; girar el pomo y tirar 
de la puerta; separarse al mover la puerta, etc.). 


Consuo 


Como diseñador, trabaje mucho y duro poro derivar 
obstracciones tonto procedimentales como de datos 
quesirvan poro el problema que tengo en ese momento, 
pero que tombién se puedon volver a utilizar en otros 
sifuaciones. 


Una abstracción de datos es una colección nombra- 
da de datos que describe un objeto de datos (Capítulo 
12). En el contexto de la abstracción procedimental 
abrir, podemos definir una abstracción de datos llama- 
da puerta. Al igual que cualquier objeto de datos, la 


2 En el Capítulo 19 se presenta un estudio más detallado sobre 
los factores de calidad. 
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abstracción de datos para puerta acompañaría a un con- 

junto de atributos que describen esta puerta (por ejem- 
plo, tipo de puerta, dirección de apertura, mecanismo 
de apertura, peso, dimensiones). Se puede seguirdicien- 
do que la abstracción procedimental abrir hace uso de 
la información contenida en los atributos de la abstrac- 
ción de datos puerta. 

La abstracción de control es la tercera forma de 
abstracción que se utiliza en el diseño del software. Al 
igual que las abstracciones procedimentales y de datos, 
este tipo de abstracción implica un mecanismo de con- 
trol de programa sin especificar los datos internos. Un 
ejemplo de abstracción de control es el semáforo de 
sincronización [KA183] que se utiliza para coordinar 
las actividades en un sistema operativo. El concepto 
de abstracción de control se estudia brevemente en el 
Capítulo 14. 


13,4.2. Refinamiento 


El refinamiento paso a paso es una estrategia de diseño 
descendente propuesta originalmente por Niklaus Wirth 
[WIR71]. El desarrollo de un programa se realiza refi- 
nando sucesivamente los niveles de detalle procedimen- 
tales. Una jerarquía se desarrolla descomponiendo una 
sentencia macroscópicade función (una abstracción pro- 
cedimental) paso a paso hasta alcanzarlas sentenciasdel 
lenguaje de programación. Wirth [WIR71] proporciona 
una visión general de este concepto: 


En cada paso (del refinamiento), se descompone una o varias 
instrucciones del programa dado en instrucciones más detalla- 
das. Esta descomposición sucesiva o refinamientode especifi- 
caciones termina cuando todas las instrucciones se expresan 
en función de cualquier computadora subyacente o de cual- 
quier lenguaje de programación... De la misma manera que se 
refinan las tareas, los datos también se tienen que refinar, des- 
componer o estructurar, y es natural refinar el programa y las 
especificaciones de los datos en paralelo. 


Todos los pasos del refinamiento implican decisiones de 
diseño. Es importante que.. . el programador conozca los cri- 
terios subyacentes (para decisiones de diseño) y la existencia 
de soluciones alternativas., . 


El proceso de refinamiento de programas propuesto 
por Wirth es análogo al proceso de refinamiento y de 
partición que se utiliza durante el análisis de requisitos. 
La diferencia se encuentra en el nivel de detalle de 
implementación que se haya tomado en consideración, 
no en el enfoque. 


loop 


Existe la tendencia de entrar en detalleinmediatamente, 
saltándose los pasos de refinamiento. Esto conduce o 
errores y omisiones y hace que el diseño seo más difícil 
de revisar. Realice el refinamientopaso a paso. 


El refinamiento verdaderamente es un proceso de 
elaboración. Se comienza con una sentencia de función 


(o descripción de información) que se define a un nivel 
alto de abstracción. Esto es, la sentencia describe la fun- 
ción o información conceptualmente, pero no propor- 
ciona información sobre el funcionamiento interno de 
la información. El refinamiento hace que el diseñador 
trabaje sobre la sentencia original, proporcionandocada 
vez más detalles a medida que van teniendo lugar suce- 
sivamente todos y cada uno de los refinamientos (ela- 
boración). 


13.43. Modularidad 


El concepto de modularidad se ha ido exponiendo des- 
de hace casi cinco décadas en el software de computa- 
dora. La arquitectura de computadora (descrita en la 
Sección 13.4.4) expresa la modularidad; es decir, el 
software se divide en componentes nombrados y abor- 
dados por separado, llamados frecuentemente módu- 
los, que se integran para satisfacer los requisitos del 
problema. 

Se ha afirmado que «la modularidad es el Único atri- 
buto del software que permite gestionar un programa 
intelectualmente»[MYE78]. El software monolítico (es 
decir, un programa grande formado por un Único módu- 
lo) no puede ser entendido fácilmente por el lector. La 
cantidad de rutas de control, la amplitud de referencias, 
la cantidad de variables y la complejidad global hará 
que el entendimiento esté muy cerca de ser imposible. 
Para ilustrar este punto, tomemos en consideración el 
siguiente argumento basado en observaciones humanas 
sobre la resolución de problemas. 

Pensemos que C(x) es una función que define la com- 
plejidad percibida de un problema x, y que Efx) es una 
función que define el esfuerzo (oportuno) que se requie- 
re para resolver un problema x. Para dos problemas p, 


Y Pp Si 


C(p,) > Cíp») (13.1a) 
implica que 
E(p¡) > Elp») (13.1b) 


siempre hoy uno solución fácil 
r problema —cora, plausible 


En general, este resultado es por intuición obvio. Se 
tarda más en resolver un problema difícil. 

Mediante la experimentación humana en la resolu- 
ción de problemas se ha averiguado otra característica 
interesante. Esta es, 


C(p, +P2)>Cl(p¡) + C(p>) 


La ecuación (13.2) implica que la complejidad per- 
cibida de un problema que combina p, y p, es mayor 


(13.2) 
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que la complejidad percibida cuando se considera cada 
problema por separado. Teniendo en cuenta la ecuación 
(13.2) y la condición implicada por la ecuación (13.1), 
se establece que 


Elp, +P>) > Elp,) + Elp») (13.3) 

Esto lleva a una conclusión: «divide y vencerás» —+es 
más fácil resolver un problema complejo cuando se rom- 
pe en piezas manejables —. El resultado expresado en la 
ecuación (13.3) tiene implicacionesimportantesen lo que 
respecta a la modularidad y al software. Es, de hecho, un 
argumento para la modularidad. 


Consofh 


No modularice de más. la simplicidad de cada módulo 
se elipsará con la complejidad de la integración. 


Es posible concluir de la ecuación (13.3) que si sub- 
dividimos el software indefinidamente, el esfuerzo que 
se requiere para desarrollarlo sería mínimo. Desgracia- 
damente, intervienen otras fuerzas, que hacen que esta 
conclusión sea (tristemente) falsa. Como muestra la 
Figura 13.2,el esfuerzo (coste) para desarrollar un módu- 
lo de software individual disminuye a medida que 
aumenta el número total de módulos. Dado el mismo 
conjunto de requisitos, tener más módulos conduce a un 
tamaño menor de módulo. Sin embargo, a medida que 
aumenta el número de módulos, también crece el esfuer- 
zO (coste) asociadocon la integración de módulos. Estas 
características conducen también a la curva total del cos- 
te o esfuerzo que se muestra en la figura. Existe un núme- 
ro M de módulos que daría como resultado un coste 
mínimo de desarrollo, aunque no tenemos la sofistica- 
ción necesaria para predecir M con seguridad. 

Las curvas que se muestran en la Figura 13.2 pro- 
porcionan en efecto una guía útil cuando se tiene en 
consideración la modularidad. La modularidad debe- 
rá aplicarse, pero teniendo cuidado de estar próximo 
aM. Se deberá evitar modularizar de más o de menos. 
Pero, ¿cómo conocemos el entorno de M? ¿Cuánto se 
deberá modularizar el software? Para responder a estas 
preguntas se deberán comprender los conceptos de 
diseño que se estudiarán más adelante dentro de este 
capítulo. 


Referencia cruzada 


los métodos de diseño se estudian en los Capítulos 14, 
15, 16 y 22. 


Cuando se tiene en consideración la modularidad 
surge otra pregunta importante. ¿Cómo se define un 
módulo con un tamaño adecuado? La respuesta se 
encuentra en los métodos utilizados para definir los 
módulos dentro de un sistema. Meyer [MEY88] define 
cinco criterios que nos permitirán evaluar un método de 
diseño en relación con la habilidad de definir un siste- 
ma modular efectivo: 
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? ¿Cómo se puede evaluar un método 

de diseño para determinar si va a 
conducir a una modularidad efectiva? 


Capacidad de descomposición modular. Si 
un método de diseño proporciona un mecanismo 
sistemático para descomponer el problema en sub- 
problemas, reducirá la complejidad de todo el pro- 
blema, consiguiendo de esta manera una solución 
modular efectiva. 


Capacidad de empleo de componentes modu- 
lares. Si un método de diseño permite ensamblar los 
componentes de diseño (reusables) existentes en un 
sistema nuevo, producirá una solución modular que 
no inventa nada ya inventado. 


Capacidad de comprensión modular. Si un 
módulo se puede comprender como una unidad autó- 
noma (sin referencias a otros módulos) será más fácil 
de construir y de cambiar. 


' Coste total 
| ¡ del software 


1 
7 | Coste a 
Región de coste es de integración 


mínimo 


Coste de » 8u srzo 


Coste/ módulo 


Número de módulos 
FIGURA 13.2. Modularidad y costes de software. 


Continuidad modular. Si pequeños cambios en 
los requisitos del sistema provocan cambios en los 
módulos individuales, en vez de cambios generali- 
zados en el sistema, se minimizará el impacto de los 
efectos secundarios de los cambios. 


Protección modular. Si dentro de un módulo se 
produce una condición aberrante y sus efectos se 
limitan aese módulo, se minimizará el impacto de 
los efectos secundarios inducidos por los errores. 


Finalmente, es importante destacar que un sistema 
se puede diseñar modularmente, incluso aunque su 
implementación deba ser «monolítica». Existen situa- 
ciones (por ejemplo, software en tiempo real, software 
empotrado) en donde no es admisible que los subpro- 
gramas introduzcan sobrecargas de memoria y de velo- 
cidad por mínimos que sean (por ejemplo, subrutinas, 
procedimientos). En tales situaciones el software podrá 
y deberá diseñarse con modularidad como filosofía pre- 
dominante. El código se puede desarrollar «en línea». 
Aunque el código fuente del programa puede no tener 
un aspecto modular a primera vista, se ha mantenido la 
filosofía y el programa proporcionará los beneficios de 
un sistema modular. 
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13.4,4, Arquitectura del software 


La arquitectura del software alude a la «estructura glo- 
bal del software y a las formas en que la estructura pro- 
porciona la integridad conceptual de un sistema» 
[SHA95a]. En su forma más simple, la arquitectura es 
la estructura jerárquica de los componentes del pro- 
grama (módulos), la manera en que los componentes 
interactúan y la estructura de datos que van a utilizar 
los componentes. Sin embargo, en un sentido más 
amplio, los «componentes» se pueden generalizar para 
representar los elementos principales del sistema y sus 
interacciones”, 


Referencia Web] * 


Lo STARS Software Architecture Technology Guide 
proporciona mbs información y recursos en la dirección 
www-ast.tds-qn.Imco.com/arch/guide.html 


Un objetivo del diseño del software es derivar una 
representación arquitectónica de un sistema. Esta repre- 
sentación sirve como marco de trabajo desde donde se 
llevan a cabo actividades de diseño más detalladas. Un 
conjunto de patrones arquitectónicos permiten que el 
ingeniero del software reutilice los conceptos a nivel de 
diseño. 


de soffwore es el producto 
orrollo que ofrece la mayor 
en lo que se refiere o calidad, 


Shaw y Garlan [SHA95a] describen un conjunto de 
propiedades que deberán especificarse como parte de 
un diseño arquitectónico: 


Propiedades estructurales. Este aspecto de la representa- 
ción del diseño arquitectónico define los componentes de un 
sistema (por ejemplo, módulos, objetos, filtros) y la manera 
en que esos componentes se empaquetan e interactúan unos 
con otros. Por ejemplo, los objetos se empaquetan para encap- 
sular tanto los datos como el procesamiento que manipula los 
datos e interactúan mediante la invocación de métodos (Capí- 
tulo 20). 


Propiedades extra-funcionales. La descripción del diseño 
arquitectónico deberá ocuparsede cómo la arquitectura de dise- 
ño consigue los requisitos para el rendimiento, capacidad, fia- 
bilidad, seguridad,capacidad de adaptación y otras características 
del sistema. 


3 Por ejemplo, los componentes arquitectónicos de un sistema 


cliente/servidor se representan en un nivel de abstracción diferente. 


Para más detalles véase el Capítulo 28. 
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Familias de sistemas relacionados.El diseño arquitectóni- 
co deberá dibujarse sobre patrones repetibles que se basen 
comúnmente en el diseño de familias de sistemas similares. En 
esencia, el diseño deberá tener la habilidad de volver a utilizar 
los bloques de construcción arquitectónicos. 


Dada la especificación de estas propiedades, el 
diseño arquitectónico se puede representar median- 
te uno Oo más modelos diferentes [GAR95]. Los 
modelos estructurales representan la arquitectura 
como una colección organizada de componentes de 
programa. Los modelos del marco de trabajo aumen- 
tan el nivel de abstracción del diseño en un intento 
de identificar los marcos de trabajo (patrones) repe- 
tibles del diseño arquitectónico que se encuentran en 
tipos similares de aplicaciones. Los modelos diná- 
micos tratan los aspectos de comportamiento de la 
arquitectura del programa, indicando cómo puede 
cambiar la estructura o la configuración del sistema 
en función de los acontecimientos externos. Los 
modelos de proceso se centran en el diseño del pro- 
ceso técnico de negocios que tiene que adaptar el sis- 
tema. Finalmente los modelos funcionales se pueden 
utilizar para representar la jerarquía funcional de un 


sistema. 
S 
A 
VE 


Poro representar el diseño arquitectónico se utilizan 
cinco tipos diferentes de modelos. 


Se ha desarrollado un conjunto de lenguajes de des- 
cripción arquitectónica (LDASs) para representar los 
modelos destacados anteriormente [SHA95b]. Aunque 
se han propuesto muchos LDASs diferentes, la mayoría 
proporcionan mecanismos para describir los compo- 
nentes del sistema y la manera en que se conectan unos 
con otros. 


13,4.5, Jerarquía de control 


La jerarquía de control, denominada también estructu- 
ra de programa, representa la organización de los com- 
ponentes de programa (módulos)e implica una jerarquía 
de control. No representa los aspectos procedimentales 
del software, ni se puede aplicar necesariamente a todos 
los estilos arquitectónicos. 


Enel Capítulo 14 se presenta un estudio detallado 
de estilos y patrones arquitectónicos. 
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Para representar lajerarquía control de aquellos esti- 
los arquitectónicosque se avienen a la representación se 
utiliza un conjunto de notaciones diferentes. El diagra- 
ma más común es el de forma de árbol (Fig. 13.3) que 
representa el controljerárquico para las arquitecturas de 
llamada y de retorno”. Sin embargo, otras notaciones, 
tales como los diagramas de Warnier-Orr [ORR77] y 
Jackson [JAC831 también se pueden utilizar con igual 
efectividad. Con objeto de facilitar estudios posteriores 
de estructura, definiremos una serie de medidas y térmi- 
nos simples. Según la Figura 13.3, la profundidad y la 
anchura proporcionan una indicación de la cantidad de 
niveles de control y el ámbito de control global, respec- 
tivamente. El grado de salida es una medida del núme- 
ro de módulos que se controlan directamente con otro 
módulo. El grado de entrada indica la cantidad de módu- 
los que controlan directamente un módulo dado. 


M 
Grado de salida 


JJ 1) 
rofundidad 
d e k 
pal a]: PRA 


"=> Anchura 


FIGURA 13.3. Terminologías de estructura para un estilo 
arquitectónico de llamada y retorno. 


a] 


soil 


La relación de control entre los módulos se expresa 
de la manera siguiente: se dice que un módulo que con- 
trola otro módulo es superior a él, e inversamente, se 
dice que un módulo controlado por otro módulo es 
subordinado del controlador [Y0U79]. Por ejemplo, en 
la Figura 13.3 el módulo M es superior a los módulos 
a, b y c. El módulo h está subordinado al módulo e y 
por Último está subordinado al módulo M. Las relacio- 
nes en anchura (por ejemplo, entre los módulos d y e), 
aunque en la práctica se puedan expresar, no tienen que 
definirse con terminología explícita. 


Cionsuof) 


Sidesorrollamos un software orientado o objetos, 
no se aplicarán los medidos estructurales destacadas 
aquí. Sin embargo, se aplicarán otros (las que se 
abordan en lo Porte Cuarta). 


4 Una arquitectura de llamada y de retorno (Capítulo 14)es una estruc- 
tura de programa clásica que descompone la función en una jerar- 
quía de control en donde el programa «principal» invoca un número 
de componentes de programa que a su vez pueden invocar aún a 
otros componentes. 
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La jerarquía de control también representa dos carac- 
terísticas sutiles diferentes de la arquitectura del soft- 
ware: visibilidad y conectividad. La visibilidad indica 
el conjunto de componentes de programa que un com- 
ponente dado puede invocar o utilizar como datos, inclu- 
so cuando se lleva a cabo indirectamente. Por ejemplo, 
un módulo en un sistema orientado a objetos puede acce- 
der al amplio abanico de objetos de datos que haya here- 
dado, ahora bien solo utiliza una pequeña cantidad de 
estos objetos de datos. Todos los objetos son visibles 
para el módulo. La conectividad indica el conjunto de 
componentes que un componente dado invoca o utiliza 
directamente como datos. Por ejemplo, un módulo que 
hace directamente que otro módulo empiece la ejecu- 
ción está conectado a él', 


13.4.6. División estructural 


Si el estilo arquitectónico de un sistema es jerárquico, 
la estructura del programa se puede dividir tanto hori- 
zontal como verticalmente. En la Figura 13.4.a la par- 
tición horizontal define ramas separadas de lajerarquía 
modular para cada función principal del programa. Lo 
módulos de control, representados con un sombreado 
más oscuro se utilizan para coordinar la comunicación 
entre ellos y la ejecución de las funciones. El enfoque 
más simple de la división horizontal define tres parti- 
ciones -entrada, transformación de datos (frecuente- 
mente llamado procesamiento) y salida—. La división 
horizontal de la arquitectura proporciona diferentes 
ventajas: 


proporciona software más fácil de probar 


conduce a un software más fácil de mantener 


propaga menos efectos secundarios 
proporciona software más fácil de ampliar 


¿Cuales son las ventajas 
de la partición horizontal? 


Como las funciones principales se desacoplan las 
unas de las otras, el cambio tiende a ser menos com- 
plejo y las extensiones del sistema (algo muy común) 
tienden a ser más fáciles de llevar a cabo sin efectos 
secundarios. En la parte negativa la división horizontal 
suele hacer que los datos pasen a través de interfaces de 
módulos y que puedan complicar el control global del 
flujo del programa (si se requiere un movimiento rápi- 
do de una función a otra). 


5 En el Capítulo 20, exploraremos el concepto de herencia para el 
software orientado a objetos. Un componente de programa puede 
heredar una lógica de control y/o datos de otro componente sin refe- 
rencia explícita en el código fuente. Los componentes de este tipo 
serán visibles, pero no estarán conectados directamente. Un dia- 
grama de estructuras (Capítulo 14) indica la conectividad. 
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La división vertical (Fig. 13.4.b), frecuentemente lla- 
mada factorización (factoring) sugiere que dentro de la 
estructura de programa el control (toma de decisiones) y 
el trabajo se distribuyan de manera descendente. Los 
módulos del nivel superior deberán llevar a cabo funcio- 
nes de control y no realizarán mucho trabajo de procesa- 
miento. Los módulos que residen en la parte inferior de 
la estructura deberán ser los trabajadores, aquellos que 
realizan todas las tareas de entrada, proceso y salida. 

La naturaleza del cambio en las estructuras de progra- 
mas justifica la necesidad de la división vertical. En la Figu- 
ra 13.4b se puede observar que un cambio en un módulo 
de control (parte superiorde la estructura) tendrá una pro- 
babilidad mayor de propagar efectos secundarios a los 
módulos subordinados a él. Un cambio en el módulo de 
trabajador, dado su nivel bajo en la estructura, es menos 
probable que propague efectossecundanos.En general, los 
cambios en los programas de computadora giran alrededor 
del programa (es decir, su comportamientobásico es menos 
probable que cambie). Por esta razón las estructuras con 
división vertical son menos susceptibles a los efectos secun- 
darios cuando se producen cambios y por tanto se podrán 
mantener mejor —un factor de calidad clave—. 


“a 
LAVE 


los módulos de «trabajador» tienden a cambiar de forma 
más frecuente que los módulos de control. Si se colocan 
en la parte inferior de la estructura, se reducen los efectos 
secundarios (originados por el cambio). 


134.7, Estructura de datos 


La estructura de datos es una representación de la rela- 
ción lógica entre elementosindividualesde datos. Como 
la estructura de la información afectará invariablemen- 
te al diseño procedimental final, la estructura de datos 
es tan importante como la estructura de programa para 
la representación de la arquitectura del software. 


Función 1 Función 


ia 


A 


(a) División horizontal 


uuu 
Función3 


Módulos 
de toma 
de decisiones 


Módulos 
de «trabajo» 


an 


(b) División Vertical 


FIGURA 13.4. Partición estructural. 
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La estructura dicta las alternativas de organización, 
métodos de acceso, grado de capacidad de asociación 
y procesamiento de la información. Se han dedicado 
libros enteros (por ejemplo, [AHO83], [KRU84]), 
[GAN39)) a estos temas, y un estudio más amplio sobre 
este tema queda fuera del ámbito de este libro. Sin 
embargo, es importante entender la disponibilidad de 
métodos clásicos para organizar la información y los 
conceptos que subyacen a lasjerarquías de información. 

La organización y complejidad de una estructura de 
datos están limitados Únicamente por la ingenuidad del 
diseñador. Sin embargo, existe un número limitado de 
estructuras de datos clásicas que componen los bloques 
de construcción para estructuras más sofisticadas. 


le ideas es lo mismo 
ón de todas los cosas 


Un elemento escalar es la estructura de datos más 
simple. Como su nombre indica, un elemento escalar 
representa un solo elemento de información que pue- 
de ser tratado por un identificador; es decir, se puede 
lograr acceso especificando un sola dirección en 
memoria. El tamaño y formato de un elemento esca- 
lar puede variar dentro de los límites que dicta el len- 
guaje de programación. Por ejemplo, un elemento 
escalar puede ser: una entidad lógica de un bit de tama- 
ño; un entero o número de coma flotante con un tama- 
ño de 8 a 64 bits; una cadena de caracteres de cientos 
o miles de bytes. 

Cuando los elementos escalares se organizan como 
una lista o grupo contiguo, se forma un vector secuen- 
cial, Los vectores son las estructuras de datos más comu- 
nes y abren la puerta a la indexación variable de la 
información. 

Cuando el vector secuencial se amplía a dos, tres y 
por último a un número arbitrario de dimensiones, se 
crea un espacio n-dimensional. El espacio n-dimensio- 
nal más común es la matriz bidimensional. En muchos 
lenguajes de programación, un espacio n-dimensional 
se llama array. 

Los elementos, vectores y espacios pueden estar orga- 
nizados en diversos formatos. Una lista enlazada es una 
estructura de datos que organiza elementos escalaresno 
contiguos, vectores o espacios de manera (llamados 
nodos) que les permita ser procesados como una lista. 
Cada nodo contiene la organización de datos adecuada 
(por ejemplo, un vector) o un puntero o más que indi- 
can la dirección de almacenamiento del siguiente nodo 
de la lista. Se pueden añadir nogos en cualquier pun- 
to de la lista para adaptar una entrada nueva en la lista. 

Otras estructuras de datos incorporan o se constru- 
yen mediante las estructuras de datos fundamentales 
descritas anteriormente. Por ejemplo, una estructura de 
datos jerárquica se implementa mediante listas mul- 
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tienlazadas que contienen elementos escalares, vecto- 
res y posiblemente espacios n-dimensionales. Una 
estructurajerárquica se encuentra comúnmente en apli- 
caciones que requieren categorización y capacidad de 
asociación. 


Ronsuof) 


Invierta por lo menos todo el tiempo que necesite 
diseñando estructuras de datos, el mismo que pretende 
invertir diseñando algoritmos poro manipularlos. 

Si es así, se ahorrará mucha tiempo. 


Es importante destacar que las estructuras de datos, al 
igual que las estructuras de programas, se pueden repre- 
sentar a diferentes niveles de abstracción. Por ejemplo, 
una pila es un modelo conceptual de una estructura de 
datos que se puede implementarcomo un vector O una lis- 
taenlazada. Dependiendo del nivel de detalle del diseño, 
los procesos internos de la pila pueden especificarseo no. 


13,4,8. Procedimiento de software 


La estructura de programa define la jerarquía de con- 
trol sin tener en consideración la secuencia de proceso 
y de decisiones. El procedimiento de software se centra 
en el procesamiento de cada módulo individualmente. 
El procedimiento debe proporcionar una especificación 
precisa de procesamiento, incluyendo la secuencia de 
sucesos, los puntos de decisión exactos, las operaciones 
repetitivas e incluso la estructura/organización de datos. 
Existe, por supuesto, una relación entre la estructura 
y el procedimiento. El procesamiento indicadopara cada 
módulo debe incluir una referencia a todos los módulos 
subordinados al módulo que se está describiendo. Es 
decir, una representación procedimental del software se 
distribuye en capas como muestra la Figura 13.5*, 


CAPITULO 13 CONCEPTOS Y PRINCIPIOS DE DISENO 


13.4.9. Ocultación de información 


El concepto de modularidad conduce a todos los dise- 
ñadores de software a formularse una pregunta impor- 
tante: «¿Cómo se puede descomponer una solución de 
software para obtener el mejor conjunto de módulos?» 
El principio de ocultación de información [PAR72] 
sugiere que los módulos se caracterizan por las deci- 
siones de diseño que (cada uno) oculta al otro. En otras 
palabras, los módulos deberán especificarse y diseñar- 
se de manera que la información (procedimiento y datos) 
que está dentro de un módulo sea inaccesible a otros 
módulos que no necesiten esa información. 

Ocultación significa que se puede conseguir una 
modularidad efectiva definiendo un conjunto de módu- 
los independientes que se comunican entre sí inter- 
cambiando sólo la información necesaria para lograr la 
función del software. La abstracción ayuda a definir las 
entidades (o información). 


Procedimiento 
para el módulo 
superior 


Procedimiento 
para el módulo 
subordinado 


Procedimiento 
para el último módulo 
subordinado 


FIGURA 13.5. El procedimiento se distribuye en capas. 


Los conceptos fundamentales de diseño descritos en la 
sección anterior sirven para incentivar diseños modula- 
res. De hecho, la modularidad se ha convertido en un 
enfoque aceptado en todas las disciplinas de ingeniería. 
Un diseño modular reduce la complejidad (véase la Sec- 
ción 13.4.3), facilita los cambios (un aspecto crítico de 
la capacidad de mantenimiento del software), y da como 
resultado una implementación más fácil al fomentar el 
desarrolloparalelo de las diferentespartes de un sistema. 


135.1. Independencia funcional 


El concepto de independenciafuncional es la suma de 
la modularidad y de los conceptos de abstracción y ocul- 


6 Esto no es verdad para todas las estructuras arquitectónicas, Por 
ejemplo, la estratificaciónjerárquica de procedimientos no se encuen- 
tra en arquitecturas orientadas a objetos. 
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tación de información. En referencias obligadas sobre 
el diseño del software, Pamas [PAR72] y Wirth [WIR71] 
aluden a las técnicas de refinamiento que mejoran la 
independencia de módulos. Trabajos posteriores de Ste- 
vens, Wyers y Constantine [STE74] consolidaron el con- 


cepto. 
Rionsuof) 


Uncódigo es «determinante» si se describe con 
una sola oración —sujeto, verbo y predlcada — 


La independencia funcional se consigue desarrollan- 
do módulos con una función «determinante» y una «aver- 
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sión» a una interacción excesiva con otros módulos. 
Dicho de otra manera, queremos diseñar el software de 
manera que cada módulo trate una subfunción de requi- 
sitos y tenga una interfaz sencilla cuando se observa des- 
de otras partes de la estructura del programa. Es justo 
preguntarse por qué es importante la independencia. El 
software con una modularidad efectiva, es decir, módu- 
los independientes, es más fácil de desarrollar porque la 
función se puede compartimentary las interfaces se sim- 
plifican (tengamos en consideración las ramificaciones 
cuando el desarrollo se hace en equipo). Los módulos 
independientes son más fáciles de mantener (y probar) 
porque se limitan los efectos secundarios originados por 
modificaciones de diseño/código; porque se reduce la 
propagación de errores; y porque es posible utilizar 
módulos usables. En resumen, la independencia fun- 
cional es la clave para un buen diseño y el diseño es la 
clave para la calidad del software. 

La independencia se mide mediante dos criterios cua- 
litativos: la cohesión y el acoplamiento. La cohesión es 
una medida de la fuerza relativa funcional de un módu- 
lo. El acoplamiento es una medida de la independencia 
relativa entre los módulos. 


13,5.2, Cohesión 


La cohesión es una extensión natural del concepto de 
ocultación de información descrito en la Sección 13.4.8. 
Un módulo cohesivo lleva a cabo una sola tarea dentro 
de un procedimiento de software, lo cual requiere poca 
interacción con los procedimientos que se llevan a cabo 
en otras partes de un programa. Dicho de manera sen- 
cilla, un módulo cohesivo deberá (idealmente) hacer 
una sola cosa. 


e 
AVE 


la cohesión es una indicacióncualitativa del grado 
que tiene un módulo para centrarse en una sola cosa. 


La cohesión se puede representarcomo un «espectro». 
Siempredebemos buscar la cohesión más alta, aunque la 
parte media del espectro suele ser aceptable. La escala de 
cohesión no es lineal. Es decir, la parte baja de la cohe- 
sión es mucho «peor» que el rango medio, que es casi tan 
«bueno»comola parte alta de la escala. En la práctica, un 
diseñador no tiene que preocuparse de categorizar la cohe- 
siónen un módulo específico. Más bien, se deberáenten- 
der el concepto global, y asíse deberán evitarlos niveles 
bajos de cohesión al diseñar los códigos. 

En la parte inferior (y no deseable) del espectro, 
encontraremos un módulo que lleva a cabo un conjunto 
de tareas que se relacionan con otras débilmente, si es 
que tienen algo que ver. Tales módulos se denominan 
coincidentalmente cohesivos. Un módulo que realiza 
tareas relacionadas lógicamente (por ejemplo, un módu- 
lo que produce todas las salidas independientementedel 
tipo) es lógicamente cohesivo. Cuando un módulo con- 


230 


tiene tareas que están relacionadas entre sí por el hecho 
de que todas deben ser ejecutadas en el mismo interva- 
lo de tiempo, el módulo muestra cohesión temporal. 

Como ejemplo de baja cohesión, tomemos en con- 
sideración un módulo que lleva a cabo un procesamiento 
de errores de un paquete de análisis de ingeniería. El 
módulo es invocado cuando los datos calculados exce- 
den los límites preestablecidos. Se realizan las tareas 
siguientes: (1) calcula los datos complementarios basa- 
dos en los datos calculados originalmente; (2) produce 
un informe de errores (con contenido gráfico) en la esta- 
ción de trabajo del usuario; (3) realiza los cálculos de 
seguimiento que haya pedido el usuario; (4) actualiza 
una base de datos, y (5) activa un menú de selección 
para el siguiente procesamiento. Aunque las tareas ante- 
riores están poco relacionadas, cada una es una entidad 
funcional independiente que podrá realizarse mejor 
como un módulo separado. La combinación de funcio- 
nes en un solo módulo puede servir sólo para incre- 
mentar la probabilidad de propagación de errores cuando 
se hace una modificación a alguna de las tareas proce- 
dimentales anteriormente mencionadas. 


sin O 
acoplamiento 
directo 
Estructura Datos 
de datos (variables) 


Área de datos 
globales SS 


FIGURA 13.6. Tipos de acoplamiento. 


Los niveles moderados de cohesión están relativa- 
mente cerca unos de otros en la escala de independen- 
cia modular. Cuando los elementos de procesamiento 
de un módulo están relacionados, y deben ejecutarse en 
un orden específico, existe cohesión procedimental. 
Cuando todos los elementos de procesamiento se cen- 
tran en un área de una estructura de datos, tenemos pre- 
sente una cohesión de comunicación. Una cohesión alta 
se caracterizapor un módulo que realiza una única tarea. 


Cons) 


Sinos concentramos en uno sola coso durante el diseño 
anivel de componentes, hoy que realizarlo con cohesión. 


Como ya se ha mencionado anteriormente, no es 
necesario determinar el nivel preciso de cohesión. Más 
bien, es importante intentar conseguir una cohesión alta 
y reconocer cuando hay poca cohesión para modificar 
el diseño del software y conseguir una mayor indepen- 
dencia funcional. 
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El acoplamiento es una medida de interconexión entre 
módulos dentro de una estructura de software. El aco- 
plamiento depende de la complejidad de interconexión 
entre los módulos, el punto donde se realiza una entra- 
da oreferencia a un módulo, y los datos que pasan a tra- 
vés de la interfaz. 

En el diseño del software, intentamos conseguir el 
acoplamiento más bajo posible. Una conectividad sen- 
cilla entre los módulos da como resultado un software 
rás fácil de entender y menos propenso a tener un «efec- 
to ola» [STE75] causado cuando ocurren errores en un 
lugar y se propagan por el sistema. 


CLAVE 


Eacoplamiento es una indicación cualitativa 
del grado de conexión de un módulo con otros 
y con el mundo exterior. 


La Figura 13.6 proporciona ejemplos de diferentes 
tipos de acoplamiento de módulos. Los módulos a y d 
son subordinados a módulos diferentes. Ninguno está 
relacionado y por tanto no ocurre un acoplamientodirec- 
to. El módulo c es subordinado al módulo a y se acce- 
de a él mediante una lista de argumentos por la que pasan 
los datos. Siempre que tengamos una lista convencio- 
nal simple de argumentos (es decir, el paso de datos; la 
existencia de correspondencia uno a uno entre elemen- 
tos), se presenta un acoplamiento bajo (llamado aco- 
plumiento de datos) en esta parte de la estructura. Una 
variación del acoplamiento de datos, llamado acopla- 
miento de marca (stamp),se da cuando una parte de la 
estructura de datos (en vez de argumentos simples) se 
pasa a través de la interfaz. Esto ocurre entre los módu- 


los b y a. 
Qonuop 


Sistemas altamente acoplados conducen a depurar 
verdaderas pesadillas. Evítelos. 
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En niveles moderados el acoplamiento se caracte- 
riza por el paso de control entre módulos. El acopla- 
miento de control es muy común en la mayoría de los 
diseños de software y se muestra en la Figura 13.6 en 
donde un «indicador de control» (una variable que 
controla las decisiones en un módulo superior o subor- 
dinado) se pasa entre los módulos d y e. 

Cuando los módulos están atados a un entorno 
externo al software se dan niveles relativamente altos 
de acoplamiento. Por ejemplo, la E/S “acoplaun módu- 
lo a dispositivos, formatos y protocolos de comuni- 
cación. El acoplamiento externo es esencial, pero 
deberá limitarse a unos pocos módulos en una estruc- 
tura. También aparece un acoplamiento alto cuando 
varios módulos hacen referencia a un área global de 
datos. El acoplamiento común, tal y como se deno- 
mina este caso, se muestra en la Figura 13.8. Los 
módulos c, g y k acceden a elementos de datos en un 
área de datos global (por ejemplo, un archivo de dis- 
co o un área de memoria totalmente accesible). El 
módulo c inicializa el elemento. Más tarde el módu- 
lo g vuelve a calcular el elemento y lo actualiza. 
Supongamos que se produce un error y que g actua- 
liza el elemento incorrectamente. Mucho más adelante 
en el procesamiento, el módulo k lee el elemento, 
intenta procesarlo y falla, haciendo que se interrum- 
pa el sistema. El diagnóstico de problemas en estruc- 
turas con acoplamiento común es costoso en tiempo 
y es difícil. Sin embargo, esto no significa necesaria- 
mente que el uso de datos globales sea «malo». Sig- 
nifica que el diseñador del software deberá ser 
consciente de las consecuencias posibles del acopla- 
miento común y tener especial cuidado de prevenir- 
se de ellos. 

El grado más alto de acoplamiento, acoplamiento 
de contenido, se da cuando un módulo hace uso de 
datos o de información de control mantenidos dentro 
de los límites de otro módulo. En segundo lugar, el 
acoplamiento de contenido ocurre cuando se realizan 
bifurcaciones a mitad de módulo. Este modo de aco- 
plamiento puede y deberá evitarse. 


ADE 


Una vez que se ha desarrollado una estructura de pro- 
grama, se puede conseguir una modularidad efectiva 
aplicando los conceptos de diseño que se introdujeron 
al principio de este capítulo. La estructura de programa 
se puede manipular de acuerdo con el siguiente con- 
junto de heurísticas: 


1. Evaluar la «primera iteración» de la estructura de 
programa para reducir al acoplamiento y mejorar 
la cohesión. Una vez que se ha desarrollado la 
estructura del programa, se pueden explosionar o 
implosionar los módulos con vistas a mejorar la 
independencia del módulo. Un módulo explosio- 
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nado se convierte en dos módulos o más en la 
estructura final de programa. Unmódulo implosio- 
nudo es el resultado de combinar el proceso impli- 
cado en dos o más módulos. 


5 fécnicos (de diseño) restringen 
es tomo decir que un artista puede pintor sin 
formas, o decir que un músico no 

xe teoría musical. 
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Un módulo explosionado se suele dar cuando 
existe un proceso común en dos o más módulos 
y puede redefinirse como un módulo de cohesión 
separado. Cuando se espera un acoplamiento alto, 
algunas veces se pueden implosionar los módu- 
los para reducir el paso de control, hacer refe- 
rencia a los datos globales y a la complejidad de 
la interfaz. 


[3 ) Evitar estructuras planas 


FIGURA 13.7. Estructuras de programa. 


11. Intentar minimizar las estructuras con un alto 


grado de salida; esforzarse por la entrada a 
medida que aumenta la profundidad. La estruc- 
tura que se muestra dentro de la nube en la Figura 
13.7 no hace un uso eficaz de la factorización. 
Todos los módulos están «planos», al mismo nivel 
y por debajo de un solo módulo de control. En 
general, una distribución más razonable de con- 
trol se muestra en la estructura de la derecha. La 
estructura toma una forma oval, indicando la can- 
tidad de capas de control y módulos de alta utili- 
dad a niveles inferiores. 


HI, Mantener el ámbito del efecto de un módulo dentro 


del ámbito de control de ese módulo. El ámbito del 
efecto de un módulo e se define como todos lo otros 
módulos que se ven afectados por la decisión 
tomada en el módulo e. El ámbito de control del 
módulo e se compone de todos los módulos subor- 
dinados y superiores al módulo e, En la Figura 13.7, 
si el módulo e toma una decisión que afecta al 
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VI. 


módulo r, tenemos una violación de la heurística 
TI, porque el módulo r se encuentra fuera del ámbito 
de control del módulo e. 


Evaluar las interfaces de los módulos para reducir 
la complejidad y la redundancia, y mejorar la con- 
sistencia. La complejidad de la interfaz de un 
módulo es la primera causa de los errores del soft- 
ware. Las interfaces deberán diseñarse para pasar 
información de manera sencilla y deberán ser con- 
secuentes con la función de un módulo. La incon- 
sistencia de interfaces (es decir, datos aparentemente 
sin relacionar pasados a través de una lista de argu- 
mentos u otra técnica) es una indicación de poca 
cohesión. El módulo en cuestión deberá volverse a 
evaluar. 


Definir módulos cuyafunción se pueda predecir, 
pero evitar módulos que sean demasiado restric- 
tivos. Un módulo es predecible cuando se puede 
tratar como una caja negra; es decir, los mismos 
datos externos se producirán independientemente 
de los datos internos de procesamiento”. Los 
módulos que pueden tener «memoria» interna no 
podrán predecirse a menos que se tenga mucho 
cuidado en su empleo. 


Un módulo que restringe el procesamiento a una 
sola subfunción exhibe una gran cohesión y es 
bien visto por el diseñador. Sin embargo, un 
módulo que restringe arbitrariamente el tamaño 
de una estructura de datos local, las opciones den- 
tro del flujo de control o los modos de interfaz 
externa requerirá invariablemente mantenimiento 
para quitar esas restricciones. 


Referencia Web 


Enla dirección de internet www.dacs.dtic.mil /techs/ 
design /Design.ToC.htm! se puede enconhor un informe 
detallado sobre los métodos de diseño de software entre los 
que se incluyen el estudio de todos los conceptos 

y principios de diseño que se abortan en este copítulo. 


Intentar conseguirmódulos de «entrada controlada)), 
evitando «conexiones patológicas». Esta heurística 
de diseño advierte contra el acoplamiento de conte- 
nido. El softwarees más fácil de entender y por tanto 
más fácil de mantener cuando los módulos que se 
interaccionan están restringidos y controlados. Las 
conexiones patológicas hacen referencia a bifurca- 
ciones o referencias en medio de un módulo. 


7 Un módulo de «caja negra. es una abstracción procedimental. 
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cui CEPTOS Y PRINCIPIOS DE DISEÑO 


WATLIGVAS 1 


Los principios y conceptos de diseño abordados en este 
capítulo establecen las bases para la creación del mode- 
lo de diseño que comprende representaciones de datos, 
arquitectura, interfaces y componentes. Al igual que en 
el modelo de análisis anterior al modelo, cada una de 
estas representaciones de diseño se encuentran unidas 
unas a otras y podrán sufrir un seguimiento hasta los 
requisitos del software. 

En la Figura 13.1,el modelo de diseño se repre- 
sentó como una pirámide. El simbolismo de esta for- 
ma es importante. Una pirámide es un objeto 
extremadamente estable con una base amplia y con un 
centro de gravedad bajo. Al igual que la pirámide, 


nosotros queremos crear un diseño de software que sea 
estable. Crearemos un modelo de diseño que se tam- 
balee fácilmente con vientos de cambio al establecer 
una base amplia en el diseño de datos, mediante una 
región media estable en el diseño arquitectónico y de 
interfaz, y una parte superior aplicando el diseño a 
nivel de componentes. 

Los métodos que conducen a la creación del mode- 
lo de diseño se presentan en los Capítulos 14, 15, 16 y 
22 (para sistemas orientados a objetos). Cada método 
permite que el diseñador cree un diseño estable que se 
ajuste a los conceptos fundamentales que conducen a 
un software de alta calidad. 


La Especificación del diseño aborda diferentes aspec- 
tos del modelo de diseño y se completa a medida que 
el diseñador refina su propia representación del soft- 
ware. En primer lugar, se describe el ámbito global 
del esfuerzo realizado en el diseño. La mayor parte 
de la información que se presenta aquí se deriva de 
la Especificación del sistema y del modelo de aná- 
lisis (Especificación de los requisitos del software). 

A continuación, se especifica el diseño de datos. 
Se definen también las estructuras de las bases de 
datos, cualquier estructura externa de archivos, 
estructuras internas de datos y una referencia cruza- 
da que conecta objetos de datos con archivos espe- 
cífiCOS. 

El diseño arquitectónico indica cómo se ha deri- 
vado la arquitectura del programa del modelo de aná- 
lisis. Además, para representar lajerarquía del módulo 
se utilizan gráficos de estructuras. 


Especificación del diseño del software 


Se representa el diseño de interfaces internas y exter- 
nas de programas y se describe un diseño detallado de 
la interfaz hombre-máquina. En algunos casos, se podrá 
representar un prototipo detallado del IGU. 

Los componentes — elementosde software que se 
pueden tratar por separado tales como subrutinas, fun- 
ciones O procedimientos — se describen inicialmente 
con una narrativa de procesamienfo en cualquier idio- 
ma (Castellano, Inglés). La narrativa de procesamiento 
explica la función procedimental de un componente 
(módulo). Posteriormente, se utiliza una herramienta 
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de diseño procedimental para convertir esa estructu- 
ra en una descripción estructural. 

La Especificación del diseño contiene una refe- 
rencia cruzada de requisitos. El propósito de esta refe- 
rencia cruzada (normalmente representada como una 
matriz simple) es: (1) establecer que todos los requi- 
sitos se satisfagan mediante el diseño del software, y 
(2) indicar cuales son los componentes críticos para 
la implementación de requisitos específicos. 

El primer paso en el desarrollo de la documenta- 
ción de pruebas también se encuentra dentro del docu- 
mento del diseño. Una vez que se han establecido las 
interfaces y la estructura de programa podremos desa- 
rrollar las líneas generales para comprobar los módu- 
los individuales y la integración de todo el paquete. 
En algunos casos, esta sección se podrá borrar de la 
Especificación del diseño. 

Las restricciones de diseño, tales como limitacio- 
nes físicas de memoria o la necesidad de una interfaz 
externa especializada, podrán dictar requisitos espe- 
ciales para ensamblar o empaquetar el software. Con- 
sideraciones especiales originadas por la necesidad 
de superposición de programas, gestión de memoria 
virtual, procesamiento de alta velocidad u otros fac- 
tores podrán originar modificaciones en diseño deri- 
vadas del flujo o estructura de la información. Además, 
esta sección describe el enfoque que se utilizará para 
transferir software al cliente. 

La última sección de la Especificación del diseño 
contiene datos complementarios. También se presen- 
tan descripciones de algoritmos, procedimientos alter- 
nativos, datos tabulares, extractos de otros documentos 
y otro tipo de información relevante, todos mediante 
notas especiales o apéndices separados. Será aconse- 
jable desarrollar un Manual preliminar de Operacio- 
nesiInstalación e incluirlo como apéndice para la 
documentación del diseño. 


www.elsolucionario.net 


INGENIERÍA DEL SOFTWARE. UN roruyur ruca aio 


El diseño es el núcleo técnico de la ingeniería del soft- 
ware. Durante el diseño se desarrollan, revisan y docu- 
mentan los refinamientos progresivos de la estructura 
de datos, arquitectura, interfaces y datos procedimen- 
tales de los componentes del software. El diseño da 
comoresultado representaciones del software para eva- 
luar la calidad. 

Durante las cuatro últimas décadas se han propuesto 
diferentes principios y conceptos fundamentales del 
diseño del software. Los principios del diseño sirven 
de guía al ingeniero del software a medida que avan- 
za el proceso de diseño. Los conceptos de diseño pro- 
porcionan los criterios básicos para la calidad del 
diseño. 

La modularidad (tanto en el programa como en los 
datos) y el concepto de abstracción permiten que el dise- 
ñador simplifique y reutilice los componentes del soft- 
ware. El refinamiento proporciona un mecanismo para 
representar sucesivascapas de datos funcionales. El pro- 
grama y la estructura de datos contribuyen a tener una 


visión global de la arquitectura del software, mientras 
que el procedimiento proporciona el detalle necesario 
para la implementación de los algoritmos. La oculta- 
ción de información y la independencia funcional pro- 
porcionan la heurística para conseguir una modularidad 
efectiva. 

Concluiremosnuestro estudio de los fundamentos del 
diseño con las palabras de Glendord Myers [MYE78]: 


Intentamos resolver el problema dándonos prisa en el pro- 
ceso de diseño de forma que quede el tiempo suficiente hasta 
el final del proyecto como para descubrir los errores que se 
cometieron por correr en el proceso de diseño... 


La moraleja es: ¡No te precipites durante el diseño! 
Merece la pena esforzarse por un buen diseño. 

No hemos terminado nuestro estudio sobre el dise- 
ño. En los capítulos siguientes, se abordan los métodos 
de diseño. Estos métodos combinados con los funda- 
mentos de este capítulo, forman la base de una visión 
completa del diseño del software. 


[AHO83] Aho, A.V.J., Hopcroft, y J. Ullmann, Data Struc- 
tures and Algorithms, Addison-Wesley, 1983. 


[BAS89] Bass, L., P. Clements y R. Kazman, Software Archi- 
tecture in Practice, Addison-Wesley, 1998. 


[BEL3 1] Belady, L., Foreword to Software Design: Methods 
and Techniques (L.J. Peters, autor), Yourdon Press, 1981. 


[BRO98] Brown, W.J. et al., Anti-Patterns, Wiley, 1998. 


[BUS96] Buschmann, F. et al., Pattern-Oriented Software 
Architecture, Wiley, 1996. 


[DAV95] Davis, A., 201 Principles of Software Development, 
McGraw-Hill, 1995. 

[DEN73] Dennis, J., «Modularity», in Advanced Course on 
Software Engineering, F.L. Bauer, ed., Springer-Verlag, 
Nueva York, 1973, pp. 128-182. 


[GAM95] Gamma, E.,et al, Design Patterns, Addison-Wes- 
ley, 1995. 


[GAN589] Gannet, G., Handbook of Algorithms and Data 
Structures, 2.* ed, Addison-Wesley, 1989, 


[GAR95] Garlan, D., y M. Shaw, «An Introduction to Soft- 
ware Architecture», Advances in Software Engineering 
and Knowledge Engineering, vol. 1, V. Ambriola y G, Tor- 
tora (eds.), World Scientific Publishing Company, 1995, 

[JAC75] Jackson, M.A., Principles of Program Design, Aca- 
demic Press, 1975. 


[JAC83] Jackson, M.A., System Development, Prentice-Hall, 
1983. 


[KAI83] Kaiser, S.H., The Design of OperatingS ystemsfor Small 
Computer Systems, Wiley-Inerscience, 1983, pp. 594 ss. 
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[JAC92] Jacobson, I., Object-Oriented Software Engineering, 
Addison-Wesley, 1992, 


[KRU84] Kruse R.L., Data Structures and Program Design, 
Prentice-Hall, 1984. 


[MCG91] McGlaughlin, R., «Some Notes on Program 
Design», Software Engineering Notes, vol. 16,n.* 4, Octu- 
bre 1991, pp. 53-54. 


[MYE78] Myers, G., Composite Structured Design, Van Nos- 
trand, 1978. 


[MEY88] Meyer, B., Object-Oriented Software Construction, 
Prentice-Hall, 1988. 


[MIL72] Mills, H.D., «Mathematical Foundations for Struc- 
tured Programming», Technical Report FSC7 1-6012, IBM 
Corp., Federal Systems Division, Gaithersburg, Maryland, 
1972. 


[NAS73] Nassi, I., y B. Shneiderman, «Flowchart Techni- 
ques for Structured Programming», SIGPLAN Notices, 
ACM, Agosto 1973. 


[ORR77] Orr, K.T., Structured Systems Development, Your- 
don Press, Nueva York, 1977. 


[PAR72] Parnas, D.L.,«On Criteria to be used in Decompo- 
sing Systems into Modules», CACM, vol. 14,n.? 1, Abril 
1972, pp. 221-227. 


[ROS75] Ross, D., J, Goodenough y C. Irvine, «Software 
Engineering: Process, Principies and Goals», IEEE Com- 
puter, vol. 8,n.? 5, Mayo 1975. 


[SHA95a] Shaw, M., y D. Garlan, «Formulations and For- 
malisms in Software Architecture», Volume 1000-Lectu- 
re Notes in Computer Science, Springer Verlag, 1995. 
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[SHA95b] Shaw, M. et al., «Abstractions for Software Archi- 
tecture and Tools to Suppori Them», IEEE Truns. Software 
Engineering, vol. 21, n.? 4, Abril 1995, pp. 314-335. 


[SHA96)] Shaw, M., y D. Garlan, Software Architecture, 
Prentice-Hall, 1996. 


[SOM96] Sommerville, 1., Software Engineering, 3.* ed., 
Addison-Wesley, 1989. 


[STE74] Stevens, W., G. Myers y L. Constantine, «Structu- 
red Design», IBM Systems Journal, vol. 13,n.* 2, 1974, 
pp. 115-139. 


UCAFILULU 19 uunuEPTOS Y PRINCIPIOS DE DISENO 


[WAR74] Warnier, J., Logical Constructionof Programs, Van 
Nostrand-Reinhold, 1974. 


[WAS83] Wasserman, A., «Information System Design 
Methodology», in Software Design Techniques (P. Free- 
man y A. Wasserman, eds.), 4.* ed., IEEE Computer 
Society Press, 1983, p. 43. 


[WIR71] Wirth, N., «Program Development by Stepwise 
Refinement», CACM, vol. 14,n.* 4, 1971, pp. 221-227. 


[YOU79] Yourdon, E., y L. Constantine, Structured Design, 
Prentice-Hall, 1979. 


13.1. Cuando se «escribe» un programa, ¿se está diseñan- 
do software? ¿En qué se diferencia el diseño del software 
de la codificación? 


13.2, Desarrolle tres principios de diseño adicionales que 
añadir a los destacados en la Sección 13.3. 


133. Proporcione ejemplos de tres abstracciones de datos 
y las abstracciones procedimentales que se pueden utilizar 
para manipularlos. 


13.4. Aplique un «enfoque de refinamiento paso a paso» 
para desarrollar tres niveles diferentes de abstracción pro- 
cedimental para uno o más de los programas que se mues- 
tran a continuación: 


a. Desarrolle un dispositivo para rellenar los cheques que, 
dada la cantidad numérica en pesetas, imprima la canti- 
dad en letra tal y como se requiere normalmente. 


b. Resuelva iterativamente las raíces de una ecuación trans- 
cendental. 


c. Desarrolle un simple algoritmo de planificación round- 
robin para un sistema operativo 


13,5, ¿Es posible que haya algún caso en que la ecuación 
(13.2) no sea verdad? ¿Cómo podría afectar este caso a la 
modularidad? 


13.6. ¿Cuándo deberá implementarse un diseño modular 
como un software monolítico? ¿Cómo se puede llevar a 
cabo? ¿Es el rendimiento la única justificación para la 
implementación de software monolítico? 


13.7. Desarrolle al menos cinco niveles de abstracción para 
uno de los problemas de software siguientes: 


a un vídeo-juego de su elección. 


b. un software de transformación en tres dimensiones para 
aplicaciones gráficas de computador. 


c, un intérprete de lenguajes de programación. 


d. un controlador de un robot con dos grados de libertad. 
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e. cualquier problema que hayan acordado usted y su pro- 
fesor. 


Conforme disminuye el grado de abstracción, su foco de 
atención puede disminuir de manera que en la última abs- 
tracción (código fuente) solo se necesite describir una úni- 
ca tarea. 


13.8. Obtenga el trabajo original de Parnas [PAR72] y resu- 
ma el ejemplo de software que utiliza el autor para ilustrar 
la descomposición en módulos de un sistema. ¿Cómo se 
utiliza la ocultación de información para conseguir la des- 
composición? 


13.9. Estudie la relación entre el concepto de ocultación de 
información como atributo de modularidad eficaz y el con- 
cepto de independencia del módulo. 


13.10. Revise algunos de los esfuerzos que haya realiza- 
do recientemente en desarrollar un software y realice un 
análisis de los grados de cada módulo (con una escala 
ascendente del 1 al 7). Obtenga los mejores y los peores 
ejemplos. 


13.11. Un grupo de lenguajes de programación de alto nivel 
soporta el procedimiento interno como construcción modu- 
lar. ¿Cómo afecta esta construcción al acoplamiento y a la 
ocultación de información? 


13.12. ¿Qué relación tienen los conceptos de acoplamien- 
to y de movilidad del software? Proporcione ejemplos que 
apoyen esta relación. 


13.13. Haga un estudio de la manera en que ayuda la par- 
tición estructural para ayudar a mantener el software. 


13.14. ¿Cuál es el propósito de desarrollar una estructura 
de programa descompuesta en factores? 


13.15. Describa el concepto de ocultación de información 
con sus propias palabras. 


13.16. ¿Por qué es una buena idea mantener el efecto de 
alcance de un módulo dentro de su alcance de control? 
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UN VE AMALIA 


Donald Norman ha escrito dos libros (The Design of Every- 
day Things, Doubleday, 1990, y The Psychology df Everyday 
Things, Harpercollins, 1988) que se han convertido en clá- 
sicos de literatura de diseño y es una lectura «obligada» para 
todos los que diseñan cualquier cosa que el ser humano va 
utilizar. Adams (Conceptual Blockbusting, 3." ed. Addison- 
Wesley, 1986) ha escrito un libro que es una lectura esencial 
para los diseñadores que quieren ampliar su forma de pen- 
sar. Finalmente un texto clásico de Polya (How to Solve It, 
2.” ed., Princeton University Press, 1988) proporciona un 
proceso genérico de resolver problemas que puede servir de 
ayuda a los diseñadores cuando se enfrentan con problemas 
complejos. 

Siguiendo la misma tradición, Winograd et al. (Bringing 
to Software, Addison-Wesley, 1996) aborda los diseños del 
software que funcionan, los que no funcionan y las razones. 
Un libro fascinante editado por Wixon y Ramsey (Field 
Methods Casebookfor Software Design, Wiley, 1996) sugie- 
re los «métodos de investigación de campos» (muy similares 
a los que utilizan los antropólogos) para entender cómo rea- 
lizan los usuarios el trabajo que realizan y entonces diseñar 
el software que cubra sus necesidades. Beyer y Holtzblatt 
(Contextual Design: A Customer-Centrered Approach to Sys- 
tems, Academic Press, 1997) ofrecen otra visión del diseño 
de software que integra al cliente/usuario en todos los aspec- 
tos del proceso de diseño del software. 

McConnell (Code Complete, Microsoft Press, 1993)pre- 
senta un estudio excelente de los aspectos prácticos para el 
diseño de software de computadora de alta calidad. Robert- 
son (Simple Program Design, 3. ed., Boyd éz Fraser Publis- 
hing) presenta un estudio introductoriode diseño del software 
que es útil para aquellos que empiezan a estudiar sobre el 
tema. 
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Dentro de una antología editada por Freeman y Wasser- 
man (Software Design Techniques, 4.* ed., IEEE, 1983)se 
encuentra un estudio histórico excelente de trabajos impor- 
tantes sobre diseño del software. Este trabajo de enseñanza 
reimprime muchos de los trabajos clásicos que han formado 
la base de las tendencias actuales en el diseño del software. 
Buenos estudios sobre los fundamentos del diseño de soft- 
ware se pueden encontrar en los libros de Myers [MYE78], 
Peters (Software Design: Methods and Techniques, Yourdon 
Press, Nueva York, 1981), Macro (Software Engineering: 
Concepts and Management, Prentice-Hall, 1990) y Som- 
merville (Software Engineering, Addison-Wesley, 5.* ed., 
1995). 

Tratamientos matemáticamente rigurosos del software de 
computadora se pueden encontrar en los libros de Jones (Soft- 
ware Development: A Rigourous Approach, Prentice-Hall, 
1980), Wulf (Fundamental Structures of Computer Science, 
Addison-Wesley, 1981) y Brassard y Bratley (Fundamental 
ofAlgorithmics, Prentice-Hall, 1995). 

Todos estos libros ayudan a proporcionarel fundamentoteó 
rico necesario para comprenderel software de computadora. 

Kruse (DataStructuresand Program Design, Prentice-Hall, 
1994) y Tucker et al. (Fundamental of Computing 11: Abstrac- 
tion, Data Structures, and Large Software Systems, McGraw- 
Hill, 1995)presentan una información valiosa sobre estructuras 
de datos. Las medidas de calidad de diseño presentadas desde 
una perspectiva técnica y de gestión son abordadas por Card y 
Glass (Measuring Design Quality, Prentice-Hall, 1990). 

Una amplia variedad de fuentes de información sobre el 
diseño del software y otros temas relacionados están dispo- 
nibles en Intemet. Una lista actualizada de referencias rele- 
vantes para los conceptos y métodos de diseño se puede 
encontrar en http://www.pressman5.com 
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CAPÍTULO 


1 Á DISEÑO ARQUITECTÓNICO 


L diseño se ha descrito como un proceso multifase en el que se sintetizan representacio- 
nes de la estructura de los datos, la estructura del programa, las características de la inter- 
az y los detalles procedimentales desde los requisitos de la información. Esta descripción 
es ampliada por Freeman [FRES80]: 


El diseño es una actividad en la que se toman decisiones importantes, frecuentemente de naturaleza 
estructural. Comparte con la programación un interés por la abstracción de la representación de la infor- 
mación y de las secuencias de procesamiento, pero el nivel de detalle es muy diferente en ambos casos. El 
diseño construye representaciones coherentes y bien planificadas de los programas, concentrándose en las 
interrelaciones de los componentes de mayor nivel y en las operaciones lógicas implicadas en los niveles 
inferiores... 


Como dijimos en el capítulo anterior, el diseño está dirigido por la información. Los méto- 
dos de diseño del software se obtienen del estudio de cada uno de los tres dominios del mode- 
lo de análisis. El dominio de los datos, el funcional y el de comportamiento sirven de directriz 
para la creación del diseño. 


En este capítulo se introducen los métodos requeridos para la creación de «representa- 
ciones coherentes y bien planeadas» de los datos y las capas arquitectónicas del modelo.de 
diseño. El objetivo es proporcionar un enfoque sistemático para la obtención del diseño 
arquitectónico —el anteproyecto preliminar desde el que se construye el software —. 


VISTAZO RÁPIDO 


16 es? El diseño arquitectónico repre- 
“senta la estructura de los datos y los 
componentes del programa que se 
requieren para construir un sistema 
basado en computadora. Constituye 
“el estilo arquitectónico que tendrá el 
istema, la estructura y las propie- 
lades de los componentes que ese 
sistema comprende, y las interrela- 
ciones que tienen lugar entre todos 
los componentes arquitectónicos del 
Sistema. 
sitas: lo hare? Aunque los ingenie- 
Tos del software pueden diseñar tan- 
to los datos como la arquitectura, 
“cuando se trata de construir sistemas 
«grandes y complejos, el trabajo es, a 
“menudo,asignado a especialistas. El 
diseñador de una base de datos o un 


almacén de datos crea la arquitectu-' 


.. ra de datos para el sistema. El «arqui- 
tecto del sistema» selecciona un estilo 
arquitectónico apropiado a los requi- 


sitos derivados durante el análisis de 
la ingeniería del sistema y de los 
requisitos del software. 

¿Por qué es importante? En la sección 
Vistazo rápido del capítulo anterior pre- 
guntamos: «No serías capaz de inten- 
tar construir una casa sin un plano, 
¿verdad?» Tú tampoco comenzarías el 
esbozo del plano por los bosquejos del 
diseño de tuberías de la casa. Necesi- 
tarías ver la foto completá —la casa en 
sí misma— antes de preocuparte por 
los detalles. Esto es lo que el diseño 
arquitectónico hace —proporciona la 
foto completa y asegura que lo estás 
haciendo bien—, 

¿Cuáles son los pasos? El diseño arqui- 
tectónico comienza con el diseño de 
datos y después procede a la deriva- 
ción de una ó más representaciones de 
la estructura arquitectónica del siste- 
ma. Los estilos arquitectónicos alter- 


nativos o patrones son analizados con * 
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el fin de obtener la estructura que 
mejor se ajusta a los requisitos del 
cliente y a las normas de calidad. Una 
vez que es seleccionada una de las 

: alternativas, la arquitectura se elabo- 
ra utilizando el método de diseño 
arquitectónico. 

¿Cuál es el producto obtenido? 
Durante el diseño arquitectónico se 
crea un modelo de arquitectura que 
abarca la arquitectura de datos y la 
estructura del programa. Además, se 
describen las propiedades de los com- 
ponentes y sus relaciones (interac- 
ciones). 

¿Cómo puedo estar seguro de que 
lo he heeho correctamente? En 
cada etapa, losproductos resultantes 
del diseño del software son revisados 
para clarificar, corregir, completar y 
dar consistencia acorde a los requi- 
sitos establecidos, y entre unos y 
otros. 
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INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRÁCTICO 


Shaw y Garlan [SHA96], en su libro de referencia sobre 
la materia, tratan la arquitectura del software de la 
siguiente forma: 

Incluso desde que el primer programafue divididoen módu- 
los, los sistemas de softwarehan tenido arquitecturas, y los pro- 
gramadoreshan sidoresponsablesde sus interaccionesa través 
de módulos y de las propiedades globales de ensamblaje. His- 
tóricamente, las arquitecturas han estado implícitas —bien 
como accidentes en la implementación, bien como sistemas 
legados del pasado—. Los buenos desarrolladores de softwa- 
re han adoptado, a menudo, uno o varios patrones arquitectó- 
nicos como estrategias de organización del sistema, pero 
utilizabanestos patrones de modo informal y no tenían ningún 
interés en hacerlos explícitos en el sistema resultante. 


Hoy, la arquitectura de software operativa y su repre- 
sentación y diseño explícitos se han convertido en temas 
dominantes de la ingeniería de software. 


141.1. ¿Qué es arquitectura? 


Cuando hablamos de la «arquitectura» de un edificio, 
nos vienen a la cabeza diferentes atributos. A nivel más 
básico, pensamos en la forma global de la estructura 
física. Pero, en realidad, la arquitectura es mucho más. 
Es la forma en la que los diferentes componentes del 
edificio se integran para formar un todo unido. Es la for- 
ma en la que el edificio encaja en su entorno y con los 
otros edificios de su vecindad. Es el grado en el que el 
edificio consigue su propósito fijado y satisface las nece- 
sidades de sus propietarios. Es el sentido estético de la 
estructura —el impacto visual del edificio — y el modo 
en el que las texturas, los colores y los materiales son 
combinados para crear la fachada externa y el «entor- 
no vivo» interno. Son los pequeños detalles - e 1 dise- 
ño de las instalaciones eléctricas, del tipo de suelo, de 
la colocación de tapices y una lista casi interminable —. 
Y, finalmente, es arte. 


Referencia Web 


Se puede encontrar una lista Útil de recursos de 
arquitectura de software en www2.umassd.edu/ 
SECenter /SAResources.html 


Pero, ¿qué pasa con la arquitectura de software? Bass 

y sus colegas [BA598] definen este esquivo término de 
la siguiente forma: 

La arquitectura de software de un sistema de programa o 

computación es la estructura de las estructuras del sistema, la 

cual comprende los componentes del software, las propieda- 


des de esos componentes visibles externamente, y las relacio- 
nes entre ellos. 


La arquitecturano es el software operacional. Más bien, 
es la representación que capacita al ingeniero del softwa- 
re para: (1) analizar la efectividad del diseño para la con- 
secución de los requisitos fijados, (2) considerar las 
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alternativas arquitectónicasen una etapa en la cual hacer 
cambios en el diseño es relativamentefácil, y (3) reducir 
los riesgos asociados a la construcción del software. 


sistema constituye un amplio 
'su formo y estructura —sus : 
estos encojan juntos—. 


La definición presentada anteriormente enfatiza el 
papel de los «componentes del software» en cualquier 
representación arquitectónica. En el contexto del dise- 
ño arquitectónico, un componente del software puede 
ser tan simple como un módulo de programa, pero tam 
bién puede ser algo tan complicado como incluir bases 
de datos y software intermedio («middleware») que per- 
miten la configuración de una red de clientes y servi- 
dores. Las propiedades de los componentes son aquellas 
características necesarias para entender cómo los com- 
ponentes interactúan con otros componentes. A nivel 
arquitectónico, no se especifican las propiedades inter- 
nas (por ejemplo, detalles de un algoritmo). Las rela- 
ciones entre los componentes pueden ser tan sencillas 
como una llamada de procedimiento de un módulo a 
otro, o tan complicadas como el protocolo de acceso a 
bases de datos. 

En este libro, el diseño de la arquitectura de software 
tiene en cuenta dos niveles de la pirámide del diseño 
(Fig. 13.1) —el diseño de datos y arquitectónico—. En 
este sentido, el diseño de datos nos facilita la represen- 
tación de los componentes de datos de la arquitectura. 
El diseño arquitectónico se centra en la representación 
de la estructura de los componentes del software, sus 
propiedades e interacciones. 


141.2. ¿Por qué es importante la arquitectura? 


En su libro dedicado a la arquitectura de software, Bass 
y sus colegas [BA5S98] identifican tres razones clave por 
las que la arquitectura de software es importante: 


» las representaciones de la arquitectura de software 


facilitan la comunicación entre todas las partes (par- 
tícipes) interesadas en el desarrollo de un sistema 
basado en computadora; 

la arquitectura destaca decisiones tempranas de 
diseño que tendrán un profundo impacto en todo el 
trabajo de ingeniería del software que sigue, y es tan 
importante en el éxito final del sistema como una 
entidad operacional; 


la arquitectura «constituye un modelo relativamente 
pequeño e intelectualmente comprensible de cómo 
está estructurado el sistema y de cómo trabajan jun- 
tos sus componentes» [BAS98]. 
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PAN 


El modelo arquitectónico proporciono uno visión «Gestalt» 
del sistema, permitiendo al ingeniero del software 
examinarlo como un todo. 


CAPITULO 14 DISENO ARQUITECTÓNICO 


El modelo de diseño arquitectónico y los patrones 
arquitectónicoscontenidos dentro son transferibles. Esto 
es, los estilos y patrones de arquitectura (Sección 14.3.1) 
pueden ser aplicados en el diseño de otros sistemas y 
representados a través de un conjunto de abstracciones 
que facilitan a los ingenieros del software la descrip- 
ción de la arquitectura de un modo predecible. 


Al igual que otras actividades de la ingeniería del soft- 
ware, el diseño de datos (a veces llamado arquitectura 
de datos) crea un modelo de datos y/o información que 
serepresenta con un alto nivel de abstracción (la visión 
de datos del cliente/usuario). Este modelo de datos, es 
entoncesrefinado en progresivasrepresentacionesespe- 
cificas de la implementación, que pueden ser procesa- 
das por un sistema basado en computadora. En muchas 
aplicaciones de software, la arquitectura de datos ten- 
drá una gran influencia sobre la arquitectura del soft- 
ware que debe procesarlo. 

La estructura de datos ha sido siempre una parte 
importante del diseño de software. Al nivel de los com- 
ponentes del programa, el diseño de las estructuras de 
datos y de los algoritmos asociados requeridos para su 
manipulación, son la parte esencial en la creación de 
aplicaciones de alta calidad. A nivel de aplicación, la 
traducción de un modelo de datos (derivado como par- 
te de la ingeniería de requisitos) en una base de datos 
esel punto clave para alcanzar los objetivos de nego- 
cio del sistema. A nivel de negocios, el conjunto de 
información almacenada en las diferentes bases de 
datos y reorganizada en el almacén de datos facilita la 
minería de datos o el descubrimiento de conocimien- 
toque puede influir en el propio éxito del negocio. De 
cualquier modo, el diseño de datos juega un papel muy 
importante. 


14,2.1, Modelado de datos, estructuras de datos, 
bases de datos y almacén de datos 


Los objetos de datos definidos durante el análisis de 
fequisitos del software son modelados utilizando dia- 
gramas de entidad-relación y el diccionario de datos 
(Capítulo 12). La actividad de diseño de datos traduce 
£sos elementos del modelo de requisitos en estructuras 
de datos a nivel de los componentes del software y, cuan- 
does necesario, a arquitectura de base de datos a nivel 
de aplicación. 


os es lo que marca 
un olmocén de datos 
o? 
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Durante muchos años, la arquitectura de datos estu- 
vo limitada, generalmente, a las estructuras de datos a 
nivel del programa y a las bases de datos a nivel de apli- 
cación. Pero hoy, las empresas grandes y pequeñas están 
inundadas de datos. No es inusual, incluso para una 
mediana empresa, tener docenas de bases de datos sir- 
viendo diferentes aplicaciones de cientos de gigabytes 
de datos. El desafío de las empresas ha sido extraer 
información útil de su entorno de datos, particularmen- 
te cuando la información deseada está funcionalmente 
interrelacionada (por ejemplo, información que sólo 
puede obtenerse si los datos de marketing específicos 
se cruzan con los datos de la ingeniería del producto). 

Para resolver este desafío, la comunidad de empre- 
sas de TI ha desarrollado las técnicas de minería de 
datos, también llamadas descubrimiento de conoci- 
miento en bases de datos (DCBC),que navegan a tra- 
vés de las bases de datos en un intento por extraer el 
nivel de información de negocio apropiado. Sin embar- 
go, la existencia de múltiples bases de datos, sus dife- 
rentes estructuras, el grado de detalle contenido en las 
bases de datos, y muchos otros factores hacen difícil la 
minería de datos dentro de un entorno con bases de 
datos existentes. Una solución alternativa, llamada 
almacén de datos, añade una capa adicional a la arqui- 
tectura de datos. 


Para obtener información actualizada sobre tecnologías 
de olmocén de datos visitar: 
www.dutawarehouse.com 


Un almacén de datos es un entorno de datos sepa- 
rado, que no está directamente integrado con las apli- 
caciones del día a día, pero que abarca todos los datos 
utilizados por una empresa [MAT96]. En cierto senti- 
do, un almacén de datos es una gran base de datos inde- 
pendiente, que contiene algunos, pero no todos los 
datos almacenados en las bases de datos que sirven al 
conjunto de aplicaciones requeridas en un negocio. Sin 
embargo, hay muchas características diferenciales entre 
un almacén de datos y una base de datos típica 
[INM95]: 
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Orientación por materia. Un almacén de datos 
está organizado por las materias importantes del 
negocio, más que por los procesos o funciones del 
negocio. Esto nos lleva a una exclusión de datos que 
podrían ser necesarios para una función particular 
del negocio, pero que generalmente no son necesa- 
rios para la minería de datos. 


Integración. Sin tener en cuenta la fuente de datos, 
da consistencia nombrar convenciones, unidades y 
medidas, estructuras de codificación y atributos físi- 
cos incluso cuando la inconsistenciaexiste a través de 
las diferentesbases de datos orientadas a aplicaciones. 


Restriccionesde tiempo. Para un entorno de apli- 
cación orientado a transacción, los datos son precisos 
en el momento del acceso y por un periodo de tiempo 
relativamente pequeño (normalmentede 60 a 90 días) 
antes del acceso. Sinembargo, en un almacén de datos, 
se accede a los datos en un momento específico del 
tiempo (por ejemplo, los clientes con los que se ha 
contactado el mismo día que el nuevo producto ha sido 
anunciadoen la prensa comercial). El horizonte típico 
de tiempo de un almacén de datos es de 5 a 10años. 


No volatilidad. A diferencia de las típicas bases 
de datos de aplicaciones de negocios que atraviesan 
una continua corriente de cambios (insertar, borrar, 
actualizar), en el almacén de datos los datos se car- 
gan, pero después de la primera transferencia, los 
datos no cambian. 


e, 
CLA VE 


Un almacén de datos contiene todos los datos utilizados 
en una empresa. Su objetivo esfacilitar el acceso 
a ((conocimiento)) que de otro modo no se dispondría. 


Estas características presentan un cuadro Único de 
desafíos de diseño para el arquitecto de datos. 


14.2.2. Diseño de datos a nivel de componentes 


El diseño de datos a nivel de componentes se centra 
en la representación de estructuras de datos a las que se 
accede directamente a través de uno o más componen- 
tes del software. Wasserman [WASSOJ] ha propuesto un 
conjunto de principios que pueden emplearse para espe- 
cificar y diseñar dicha estructura de datos. En realidad, 
el diseño de datos empieza durante la creación del mode- 
lo de análisis. Recordando que el análisis de requisitos 
y el diseño a menudo se solapan, consideramos el 
siguiente conjunto de principios [WASSO]para la espe- 
cificación de datos: 


1. Losprincipios del análisis sistemático aplicados a la 
función y al comportamiento deberían aplicarse tam- 
bién a los datos. Invertimos mucho tiempo y esfuerzo 
en obtener, revisar y especificarlos requisitos fun- 
cionales y el diseño preliminar. Las representaciones 
de flujo de datos y contenido deberían desarrollarse 
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y revisarse, las de objetos de datos deberían identifi- 
carse, se deberían estudiar las organizaciones alter- 
nativas de datos y debería evaluarse el impacto del 
modelado de datos sobre el diseño del software. Por 
ejemplo, la especificación de una lista enlazada con 
múltiples anillos puede satisfacer los requisitos de los 
datos pero puede llevar a un diseño del software poco 
flexible. Una organización de datos alternativanos 
podría llevar a obtener mejores resultados. 


. Todas las estructuras de datos y las operacionesa lle- 
var a cabo en cada una de ellas deberían estar clara- 
mente identificadas. El diseño de una estructura de 
datos eficaz debe tener en cuenta las operaciones que 
se van a llevar a cabo sobre dicha estructura de datos 
(vea [AHO83]). Por ejemplo, imagínese una estruc- 
tura de datos hecha con un conjunto de elementos de 
datos diversos. La estructurade datos se va a manipu- 
lar con varias funciones principales del software. Des- 
pués de la evaluación de la operación realizada sobre 
la estructura de datos, se define un tipo de datos abs- 
tracto para usarlo en el diseño del software subsiguiente. 
La especificación de los tipos de datos abstractospuede 
simplificar considerablementeel diseño del software. 


¿Qué principios son aplicables 
para el diseño de datos? 


. Se debería establecer un diccionario de datos y 
usarlopara definir el diseño de los datos y delpro- 
grama. El concepto de diccionario de datos se intro- 
dujo en el Capítulo 12. Un diccionario de datos 
representa explícitamente las relaciones entre los 
objetos de datos y las restricciones de los elementos 
de una estructura de datos. Los algoritmos que deben 
aprovecharse de estas relaciones específicas pueden 
definirse más fácilmente si existe una especificación 
de datos tipo diccionario. 


. Las decisiones de diseño de datos de bajo nivel debe- 
rían dejarse para elfinal del proceso de diseño. Se 
puede usar un proceso de refinamiento paso a paso para 
el diseño de datos. Es decir, la organización general de 
datos puede definirse durante el análisis de requisitos; 
refinarse durante los trabajos de diseño de datos y espe- 
cificarse en detalle durante el diseño a nivel de com- 
ponentes. El enfoque descendentedel diseño de día 
proporciona ventajas análogas al enfoque descendente 
del diseño de software: se diseñan y evalúan primera- 
mente los atributos estructurales principales de manera 
que se pueda establecerla arquitectura de los datos. 

5. La representación de las estructuras de datos debe- 

rían conocerla sólo aquellos módulos que deban 

hacer uso directo de los datos contenidos dentrode 
la estructura. El concepto de ocultación de infor- 
mación y el concepto relacionado de acoplamiento 

(Capítulo 13) proporciona una importante visión de 

la calidad del diseño del software. Este principio 

alude a la importancia de estos conceptos así como 
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a «la importancia de separar la visión lógica de un 7. Undiseño del software y un lenguaje de programa- 


objeto de datos de su visión física» [WASSO]. ción debería soportar la especificación y realización 

6. Debería desarrollarse una biblioteca de estructuras de los tipos abstractos de datos. La implementación 
de datos útiles y de las operaciones que se les pue- de una estructura de datos sofisticada puede hacerse 
den aplicar. Las estructuras de datos y las operacio- excesivamente difícil si no existen los medios de espe- 
nes deberían considerarse como recursos para el cificación directa de la estructura en el lenguaje de pro- 
diseño del software. Las estructuras de datos pueden gramación escogido para dicha implementación. 
diseñarse para que se puedan reutilizar. Una biblio- Los principios descritos anteriormente forman una 
teca de plantillas de estructuras de datos (tipos abs- base para un enfoque de diseño de datos a nivel de com- 
tractos de datos) puede reducir el esfuerzo del diseño ponentes que puede integrarse en las fases de análisis y 
y de la especificación de datos. diseño. 


Cuandoun constructorutiliza el término «centre hall colo- - Qué es un estilo 
e z - ¿ 
nial para describir una casa, la mayoría de la gente fami- arquitectónico 
liarizada con las casas en los Estados Unidos sería capaz 
de recrear una imagen general de cómo seríaesa casa y de 
cómo sena su diseño de plantas. El constructor ha utiliza- 14.3.1. Una breve taxonomía de estilos y patrones 
do un estilo arquitectónico a modo de mecanismo des- Aunque durante los pasados 50 años se han creado cien- 


criptivo para diferenciar esa casa de otros estilos (por tos de miles de sistemas basados en computadora, la gran 
ejemplo, A --ame, raised ranch, Cape Cod). Pero, lo más mayoría pueden ser clasificados (ver[SHA96], [BAS98], 


Importante, es que el estilo arquitectónico es también un [BUS98]) dentro de uno de los estilos arquitectónicos: 
patrón de construcción. Más adelante se deberán definir 


a - : Arquitecturas centradas de datos. En el centro de esta 
los detalles de la casa, se especificarán sus dimensiones 


arquitectura se encuentra un almacén de datos (por ejemplo, 


finales, se le añadirán características personalizadas y se un documento o una base de datos) al que otros componentes 
determinarán los materiales de construcción, pero el patrón acceden con frecuencia para actualizar, añadir, borrar o bien 
--«centre hall colonial»— guía al constructor en su tra- modificar los datos del almacén. La figura 14.1 representa un 
bajo. estilo típico basada en los datos. El software de cliente accede 


aun almacén centrai. En algunoscasos, el almacén de datos es 
pasivo. Esto significa que el software de cliente accede a los 
datos independientemente de cualquier cambio en los datos o 
Referencia de las acciones de otro software de cliente. Una variación en 
: este acceso transforma el almacén en una «pizarra» que envía 
Eproyecto ABLE de lo OVJ cuenta con trabajos y 


, 7% j E: notificaciones al software de cliente cuando los datos de inte- 
ejemplos muy útiles sobre estilos arquitectónicos: rés del cliente cambian. 


tom.cs.cmu.edu /able / 


. : Software Software 
El software construido para sistemas basados en com- del del 


putadoras también cuenta con diversos estilos arquitec- cliente cliente 
tónicos. Cada estilo describe una categoría del sistema 
que contiene: (1) un conjunto de componentes (por ejem- 
plo, una base de datos, módulos computacionales) que cliente 
realizan una función requerida por el sistema; (2) un con- 
junto de conectores que posibilitanla «comunicación, la 
coordinación y la cooperación» entre los componentes; 


Software 
del 
Sora cliente 
el 


Almacén de datos 


0% ' > - Software Software 
(3) restricciones que definen cómo se pueden integrar el del 
los componentes que forman el sistema; y (4) modelos jen cliente 


semánticos que permiten al diseñador entender las pro- 
piedades globales de un sistema para analizar las pro- 
piedades conocidas de sus partes constituyentes[BAS98]. 
En la siguiente sección, abordamos los patrones arqui- 
tectónicos comúnmente utilizados para el software. FIGURA 14.1. Arquitectura basada en los datos. 


Software Software 
del del 
cliente cliente 


'Los términos estilos y patrones se utilizan indistintamente en este 
capítulo. 
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Las arquitecturas basadas en los datos promueven la capa- 
cidad de integración (integrability) [BAS98]. Por consi- 
guiente, los componentes existentes pueden cambiarse o los 
componentes del nuevo cliente pueden añadirse a la arqui- 
tectura sin involucrar a otros clientes (porque los compo- 
nentes del cliente operan independientemente). Además, los 
datos pueden ser transferidos entre los clientes utilizando un 
mecanismo de pizarra (por ejemplo, el componente de piza- 
rra sirve para coordinar la transferencia de información entre 
clientes). Los componentes cliente son procesos ejecutados 
independientemente. 


estos de diseño está 
iplinas de ingeniería. 


Arquitecturas de flujo de datos. Esta arquitectura se 
aplica cuando los datos de entrada son transformados a tra- 
vés de una serie de componentes computacionales o mani- 
pulativos en los datos de salida. Un patrón tubería y filtro 
(Fig. 14.2.a) tiene un grupo de componentes, llamados fil- 
tros, conectados por tuberías que transmiten datos de un 
componente al siguiente. Cada filtro trabaja independien- 
temente de aquellos componentes que se encuentran en el 
flujo de entrada o de salida; está diseñado para recibir la 
entrada de datos de una cierta forma y producir una salida 
de datos (hacia el siguiente filtro) de una forma específica. 
Sin embargo, el filtro no necesita conocer el trabajo de los 
filtros vecinos. 


Siel flujo de datos degenera en una simple línea de trans- 
formadores (Fig. 14.2.b) se le denomina secuencial por 
lotes. Este patrón aplica una serie de componentes secuen- 
ciales (filtros) para transformarlos. 


orquitecto es el principal mantenedor 
“usuario del producto final. 


Arquitecturas de llamada y retorno. Este estilo arqui- 
tectónico permite al diseñador del software (arquitecto del 
sistema) construir una estructura de programa relativamente 
fácil de modificar y ajustar a escala. Existen dos subestilos 
[BAS98] dentro de esta categoría: 


e arquitecturas de programa principallsuhprograma: 
esta estructura clásica de programación descompone 
las funciones en una jerarquía de control donde un 
programa «principal» llama a un número de compo- 
nentes del programa, los cuales, en respuesta, pueden 
también llamar a otros componentes. La Figura 13.3 
representa una arquitectura de este tipo. 


arquitecturas de llamada de procedimiento remoto: 
los componentes de una arquitectura de programa 
principal/subprograma, están distribuidos entre varias 
computadoras en una red. 
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Tuberías 


| 


e pS 
(a) Tuberías y filtros 


(b) Secuencial por lotes 


FIGURA 14.2. Arquitecturas de flujo de datos. 


Referencia cruzada 


En lo Porte 4 se presento un estudio detallado sobre los 
orquitecturas orientados o objetos. 


Arquitecturas orientadas a objetos. Los componen- 
tes de un sistema encapsulan los datos y las operaciones 
que se deben realizar para manipular los datos. La comu- 
nicación y la coordinación entre componentes se consigue 
a través del paso de mensajes. 


Arquitecturas estratificadas. La estructura básica de 
una arquitectura estratificada se representa en la Figura 
14.3. Se crean diferentes capas y cada una realiza opera- 
ciones que progresivamente se aproximan más al cuadro 
de instrucciones de la máquina. En la capa externa, los 
componentes sirven a las operaciones de interfaz de usua- 
rio. En la capa interna, los componentes realizan opera- 
ciones de interfaz del sistema. Las capas intermedias 
proporcionan servicios de utilidad y funciones del soft- 
ware de aplicaciones. 


Componentes 


Capa de la interfaz 
del usuario 
Ml 
Capa 
de la aplicación 


central 


FIGURA 14.3. Arquitectura ectratificada. 
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Los estilos arquitectónicos citados anteriormente son 
sólo una pequeña parte de los que dispone el diseñador 
de software”. Una vez que la ingeniería de requisitos 
define las características y las restricciones del sistema 
que ha de ser construido, se escoge el patrón arquitec- 
tónico (estilo) o la combinación de patrones (estilos) 
que mejor encajan con las características y restriccio- 
nes. En muchos casos, puede ser apropiado más de un 
patrón y se podrían diseñar y evaluar estilos arquitec- 
tónicos alternativos. 


14,32, Organización y refinamiento 


Puesto que el proceso de diseño deja a menudo al inge- 
niero con un número de alternativas arquitectónicas, es 
importante establecer un conjunto de criterios de dise- 
ño que puedan ser utilizados para evaluar un diseño 
arquitectónico derivado. Las siguientes cuestiones 
[BAS98] proporcionan una idea del estilo arquitectó- 
nico que ha sido derivado: 


Control. ¿Cómo se gestiona el control dentro de la arqui- 
tectura? ¿Existe una jerarquía de control diferente, y si es así, 
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cuál es el papel de los componentes dentro de esajerarquía de 
control? ¿Cómo transfieren el control los componentes den- 
tro del sistema? ¿Cómo se comparte el control entre compo- 
nentes? ¿Cuál es latopología de control (por ejemplo, la forma 
geométrica? que adopta el control)?, ¿Está el control sinero- 
nizado o los componentes actúan asincrónicamente? 


% ¿Cómo se evalúa un estilo 
arquitectónico que se ha derivado? 


Datos. ¿Cómo se comunican los datos entre componen- 
tes? ¿El flujo de datos es continuo o son objetos de datos que 
pasan de un componente a otro, o los datos están disponibles 
globalmente para ser compartidos entre los componentes del 
sistema? ¿Existen los componentes de datos (por ejemplo, 
una pizarra o almacén), y si es así, cuál es su papel? ¿Cómo 
interactúan los componentes funcionales con los compo- 
nentes de datos? ¿Los componentes de datos son activos o 
pasivos (por ejemplo, los componentes de datos interactúan 
activamente con otros componentes del sistema)?¿Cómo 
interactúan los datos y el control dentro del sistema? 


Estas preguntas proporcionan al diseñador una eva- 
luación temprana de la calidad del diseño y sientan las 
bases para un análisis más detallado de la arquitectura. 


Las preguntas citadas en la sección anterior proporcio- 
nan una evaluación preliminar del estilo arquitectónico 
escogido para un sistema concreto. Sin embargo, para 
la consecución efectiva del diseño, se necesita un méto- 
do de evaluación de la calidad de la arquitectura más 
completo. En las siguientes secciones, consideramos 
dos enfoques diferentes para el análisis de diseños arqui- 
tectónicos alternativos. El primer enfoque utiliza un 
método iterativo para evaluar el diseño de los compro- 
misos. El segundo enfoque aplica una pseudotécnica 
cuantitativa para evaluar la calidad del diseño. 


fano, déjame ir arribo y mirar. 


14,41. Un método de análisis de compromiso 
para la arquitectura 


El Instituto de Ingeniería de Software (SEI)ha desa- 
rrollado un Método de análisis de compromiso para la 
arquitectura (MACA)[KAZ98] que establece un pro- 
ceso de evaluación iterativo para las arquitecturas de 
software. Las actividades de análisis de diseño men- 
cionadas abajo se realizan iterativamente: 


1. Recopilación de escenarios. En el Capítulo 11 se 
recogen un grupo de casos de uso para representar 
el sistema desde el punto de vista del usuario. 


? Ver [SHA97], [BAS98] y [BUS98] para un estudio detallado de esti- 
los y patrones arquitectónicos. 


2. Elicitación de requisitos. Esta información es reque- 
rida como parte de los requisitos de ingeniería y se 
utiliza para asegurarse de que todos los clientes, usua- 
rios y partícipes implicados han sido atendidos. 


Referencia Web 
Se puede encontrar información detallada sobre análisis 


de compromiso de software arquitectónicoen: 
www.sei.cmu.edu/ata/ata_method.html 


3. Describir lospatroneslestilos arquitectónicosescogi- 
dos para derivar los escenarios y requisitos. Ellos) 
estilo(s) debería describirse utilizando vistas arqui- 
tectónicas como: 

» vista de módulo: para analizar el trabajo asignado 
por componente y el grado de ocultación de infor- 
mación que se ha alcanzado 

» vista de proceso: para analizar la actuación del 
sistema 

= vista de flujo de datos: para analizar el grado en 
el que la arquitectura cumple los requisitos fun- 
cionales 


Referencia cruzada 


Enlos Capítulos 8 y 19 se estudianlos atributos de calidad. 


3 Una jerarquía es una forma geométrica, pero también podemos 
encontrar mecanismos de control semejantes en un sistema 
cliente /servidor. 
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4. Evaluar los atributos de calidad considerando cada 
atributo deforma aislada. El número de atributos 
de calidad escogidos para el análisis depende del 
tiempo disponible para la revisión y del grado de 
relevancia de dichos atributos para el sistema actual. 
Los atributos de calidad para la evaluación del diseño 
arquitectónico incluyen: fiabilidad, rendimiento, 
seguridad, facilidad de mantenimiento, flexibilidad, 
capacidad de prueba, movilidad, reutilización e inte- 
roperatibilidad. 


5. Identificar la sensibilidad de los atributos de cali- 
dad con los diferentes atributos arquitectónicos en 
un estilo arquitectónico específico. Esto se puede 
conseguir realizando pequeños cambios en la arqui- 
tectura y determinando cuán sensibles al cambio son 
los atributos de calidad, como el rendimiento. Aque- 
llos atributos afectados significativamente por un 
cambio en la arquitectura son denominados puntos 
sensibles. 


6. Análisis de las arquitecturas candidatas (desarro- 
lladas en el paso 3 )utilizando el análisis de sensi- 
bilidad del paso 5.El SEI describe este enfoque de 
la siguiente forma [KAZ98]: 


Una vez determinados los puntos sensibles de la arquitec- 
tura, encontrar los puntos de compromisoconsiste simplemente 
en la identificaciónde los elementosarquitectónicos en los cua- 
les varios atributos son sensibles. Por ejemplo, el rendimiento 
de una arquitecturacliente/servidor sena muy sensible al núme- 
ro de servidores (el rendimiento aumenta, dentro de un grado, 
aumentando en número de servidores). La disponibilidad de 
esa arquitectura también variaría directamente con el número 
de servidores. Sin embargo, la seguridad del sistema variaría 
inversamente al número de servidores (porque el sistema con- 
tiene más puntos de ataque potenciales). El número de servi- 
dores, entonces, es un punto de compromiso con respecto a la 
arquitectura. Este es un elemento, potencialmente uno de 
muchos, donde se harán los compromisos arquitectónicos,cons- 
ciente O inconscientemente. 

Estos seis pasos representan la primera iteración 
MACA. Tras los resultados de los pasos 3 y 6 algunas 
arquitecturas alternativas se eliminarían, una o varias 
de las arquitecturas restantes serían modificadas y pre- 
sentadas con mayor detalle, y después los pasos MACA 
se aplicarían de nuevo. 


14,4,2. Guía cuantitativa para el diseño arqui- 
tectónico 


Uno de los muchos problemas con los que se enfrentan 
los ingenieros del software durante el proceso de dise- 
ño es la carencia general de métodos cuantitativos para 
la evaluación de la calidad de los diseños propuestos. 
El enfoque MACA recogido en la Sección 14.4. 1repre- 
senta un enfoque innegablemente cualitativo y útil para 
el análisis del diseño. 


í El diseño debe ser todavía aplicable al problema actual, incluso si 
la solución no es particularmente buena. 
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Asada [SHA96] propone varios modelos simples para 
ayudar al diseñador a determinar el grado al cual una 
arquitecturaparticular alcanza los criterios de «bondad» 
predefinidos. Estos criterios, a veces llamados dimen- 
siones del diseño, a menudo abarcan los atributos de 
calidad definidos en la sección anterior: fiabilidad, ren- 
dimiento, seguridad, facilidad de mantenimiento, flexi- 
bilidad, capacidad de prueba, movilidad, reutilización 
e interoperatibilidad, entre otros. 

El primer modelo, denominado análisis del espectro, 
evalúa un diseño arquitectónicoen un espectro de «bon- 
dad» desdeel mejor diseño posible hasta el peor. Una vez 
que la arquitectura del software ha sido propuesta, se ana- 
liza asignando una «puntuación» a cada una de las 
dimensiones del diseño. Estas notas de las dimensiones 
se suman para determinar la calificación total, 5 del 
diseño como un todo. Los casos de notas más bajas' son 
asignados a un diseño hipotético, y se computa la suma 
de notas de la peor arquitectura, S, La mejor nota, Sy, 
se computa para un diseño óptimo”. Entonces calcu- 
lamos el índice del espectro, [, ,mediante la ecuación: 


1,=[(S —S,MS, =S,,)] )x 100 


El índice del espectro indica el grado al cual la arqui- 
tectura propuesta se aproxima al sistema óptimo dentro 
del espectro de alternativas razonables para el diseño. 


Si se realizan modificaciones del diseño propuesto 
O si se propone un nuevo diseño entero, los índices de 
espectro de ambos deben ser comparados y se compu- 


tará un índice de mejora, l.,,,: 


me” si - ls 
Esto proporciona al diseñador una indicación relati- 
va a la mejora asociada con los cambios arquitectóni- 
cos realizados o con la nueva arquitectura propuesta. Si 


Ine €S POSItivo, entonces podemos concluir que el sis- 
tema 1 ha sido mejorado en relación al sistema 2. 


El análisis de selección del diseño es otro modelo 
que requiere un cuadro de dimensiones de diseño para 
ser definido. La arquitectura propuesta es entonces eva: 
luada para determinar el número de dimensiones del 
diseño que se logran cuando se compara con un siste- 
ma ideal (el mejor caso). Por ejemplo, si una arquitec- 
tura propuesta alcanzara una reutilización de 
componentes excelente, y esta dimensión es requerida 
para el sistema ideal, la dimensión de reutilización ha 


5 El diseño seria Óptimo, pero las restricciones, los costes u otros fac- 
tores no permitirán su construcción. 
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sido lograda. Si la arquitectura propuesta tiene poca 
seguridad, y se necesita una gran seguridad, no se ha 
alcanzado la dimensión del diseño. 


Calculamos el índice de selección del diseño, d, 
como: 


d=(N,/N,)x100 


donde N, es el número de dimensiones de diseño logra- 
dasen la arquitectura propuesta y N, es el número total 
de dimensiones en el espacio de diseño. A mayor índi- 
ce de selección del diseño, más cerca estamos de que la 
arquitectura propuesta alcance el sistema ideal. 


El análisis de contribución «identificalas razones por 
las que un grupo de alternativas de diseño obtiene unas 
notas menores que otro». [SHA96] Retomando el estu- 
dio del despliegue de lafunción de calidad (DFC )vis- 
to en el Capítulo 11, el análisis de valor se realiza para 
determinar la prioridad relativa de los requisitos deter- 
minados durante el despliegue de funciones, el desplie- 
gue de información y el despliegue de tareas. Se identifica 
un conjunto de «mecanismos de realización» (caracte- 
rísticas de la arquitectura). Se crea un listado con todos 
losrequisitos del cliente (determinados a través del DFC) 
y una matriz de referencias cruzadas. Las celdas de la 
matriz indican (en una escala del 1 al 10)la fuerza rela- 
tiva de la relación entre un mecanismo de realización y 
un requisito para cada arquitectura propuesta. A esto se 
le conoce como espacio de diseño cuantificado (EDC). 


Hoja de cálculo DFC 
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El EDC es bastante fácil de implementar como un 
modelo de hoja de cálculo y puede ser utilizado para 
aislar porqué un cuadro de alternativas de diseño obtie- 
ne unas notas menores que otro. 


14.4.3. Complejidad arquitectónica 


Para evaluar la complejidad total de una arquitectura 
dada, una técnica útil consiste en considerar las rela- 
ciones de dependencia entre los componentes de la 
arquitectura. Estas relaciones de dependencia son con- 
ducidas a través de los flujos de información/control 
dentro del sistema. 

Zhao [ZHA98] propone tres tipos de dependencia: 


Dependencias de compartimiento, representan las relacio- 
nes de dependencia entre los consumidores que utilizan los 
mismos recursos o los productores que producen para íos mis- 
mos consumidores. Por ejemplo, tenemos dos componentes u 
y v, si u y v se refieren a los mismos datos globales, entonces 
existe una dependencia de compartimiento entre ambos. 


Dependenciasde flujo, representan las relaciones de depen- 
dencia entre los productores y los consumidores de recursos. 
Por ejemplo, entre dos componentesu y v, si u debe comple- 
tarse antes de que el control fluya a v (prerrequisito), o si u y V 
se comunican a través de parámetros, entonces existiráuna rela- 
ción de dependencia de flujo entre ambos. 


Dependencias restrictivas, representan las restricciones de 
un relativo flujo de control entre un cuadro de actividades. Por 
ejemplo, dos componentes u y v, siu y vno se pueden ejecu- 
tar al mismo tiempo (por exclusión mutua), entonces existirá 
una dependencia restrictivaentre u y v, 


Las dependencias de compartimiento y de flujo reco- 
gidas por Zhao se parecen de alguna forma al concep- 
to de acoplamiento visto en el Capítulo 13. En el 
Capítulo 19 se explicarán mediciones sencillas para la 
evaluación de las dependencias. 


¿NY Es 


En el Capítulo 13 ya dijimos que los requisitos del soft- 
ware pueden ser convertidos en varias representaciones 
del modelo de diseño. Los estilos arquitectónicos vis- 
tos en la Sección 14.3.1 representan arquitecturas radi- 
calmente diferentes, por lo cual no debería sorprendemos 
queno exista una única conversión que logre una tran- 
sición del modelo de requisitos al modelo de diseño. De 
hecho, todavía no existe una conversión para algunos 
modelos arquitectónicos, y el diseñador debe lograr la 
traducción de los requisitos del diseño para esos estilos 
de una forma ad hoc. 
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Para ilustrar un enfoque de conversión arquitectóni- 
ca, consideraremos la arquitectura de llamada y retorno 
—Ana estructura muy común para diferentes tipos de sis- 
temas —, La técnica de conversión que se presenta capa- 
cita al diseñador para derivar arquitecturasde llamada y 
retorno razonablemente complejas en diagramas de flu- 


jo de datos dentro del modelo de requisitos. 


La técnica, a veces denominada diseño estructura- 
do, tiene sus orígenes en antiguos conceptos de diseño 
que defendían la modularidad [DEN73], el diseño des- 
cendente [WIR71] y la programación estructurada 


$ También es importante mencionar que las arquitecturas de llamada 
y retorno pueden residir dentro de otras arquitecturas mas sofistica- 
das vistas anteriormente en este capitulo. Por ejemplo, la arquitec- 
tura de uno o vanos componentesde una arquitecturacliente/servidor 
podría ser de llamada y retorno. 
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[DAH72, LIN79]. Stevens, Myers y Constantine 
[STE74] propusieron el diseño del software basado en 
el fluyo de datos a través de un sistema. Los primeros 


trabajos se refinaron y se presentaron en libros de Myers 
[MYE78]1, Yourdon y Constantine |YOU79]. 


¿Cuáles son los pasos 

a seguir en la evaluación 
del DFD en una arquitectura de 
llamada y retorno? 


El diseño estructurado suele caracterizarse como un 

método de diseño orientado al flujo de datos porque per- 
mite una cómoda transición desde el diagrama de flu- 
jo de datos (DFD)a la arquitectura de software”. La 
transición desde el flujo de información (representado 
como un diagrama de flujo de datos) a una estructura 
del programa se realiza en un proceso de seis pasos: (1) 
se establece el tipo de flujo de información; (2) se indi- 
can los límites del flujo; (3) se convierte el DFD en la 
estructura del programa; (4) se define la jerarquía de 
control; (5)se refina la estructura resultante usando 
medidas y heur'sticas de diseño, y (6) se refina y ela- 
bora la descripción arquitectónica. 

El tipo de flujo de información es lo que determina 
el método de conversión requerido en el paso 3. En las 
siguientes secciones examinamos los dos tipos de flujo. 


14.5.1. Flujo de transformación 


Retomando el modelo fundamental de sistema (nivel O 
del diagrama de flujo de datos), la información debe 
introducirse y obtenerse del softwareen forma de «mun- 
do exterior». Por ejemplo, los datos escritos con un tecla- 
do, los tonos en una línea telefónica, y las imágenes de 
vídeo en una aplicación multimediason todas formas de 
información del mundo exterior. Tales datos internos 
deben convertirse a un formato interno para el procesa- 
miento. La información entra en el sistema a lo largo de 
caminos que transforman los datos externos a un for- 
mato interno. Estos caminos se identifican comoflujo de 
entrada. En el interior del software se produce una tran- 
sición. La información entrante se pasa a través de un 
centro de transformación y empieza a moverse a lo lar- 
go de caminos que ahora conducen hacia «fuera» del 
software. Los datos que se mueven a lo largo de estos 
caminos se denominan flujo de salida. El flujo general 
de datos ocurre de manera secuencial y sigue un, O unos 
pocos, caminos* «directos». Cuando un segmento de un 
diagrama de flujo de datos presenta estas características, 
lo que tenemos presente es un flujo de transformación. 


7 Debe recordarse que también durante el modelado de análisis se 
utilizan otros elementos del método de análisis (por ejemplo; el 
diccionario de datos, EP, EC). 
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Los diagramas de flujo de dotos se estudian en detalle 
en el Copítulo 12, 


14.5.2. Flujo de transacción 


El modelo fundamental de sistema implica un flujo de 
transformación; por tanto, es posible caracterizar todo 
el flujo de datos en esta categoría. Sin embargo, el flu- 
jo de información está caracterizado a menudo por un 
único elemento de datos, denominado transacción, que 
desencadena otros flujos de información a lo largo de 
uno de los muchos caminos posibles. Cuando un DED 
toma la forma mostrada en la Figura 14.4, lo que tene- 
mos es un flujo de transacción. 


UD 
Centro 


de transacción 
te 


FIGURA 14.4. Flujo de transacción. 


El flujo de transacción se caracteriza por datos que 
se mueven a lo largo de un camino de entrada que con- 
vierte la información del mundo exterior en una tran- 
sacción. La transacción se evalúa y, basándose en ese 
valor, se inicia el flujo a lo largo de uno de muchos cami- 
nos de acción. El centro del flujo de información del 
que parten muchos de los caminos de acción se deno- 
mina centro de transacción. 

Debería recalcarse que dentro del DFD de un siste- 
ma grande, ambos flujos de transacción y de transfor- 
mación pueden presentarse. Por ejemplo, en un flujo 
orientado a transacción, el flujo de información a lo lar- 
go de un camino de acción puede tener características 
de flujo de transformación. 


2 Un análisis obvio de este tipo de flujo de información lo encontra- 
mos en la Sección 14.3.1en la arquitectura de flujo de datos. Sin 
embargo, hay muchos casos en los que la arquitectura de flujo de 
datos no sería la mejor elección para un sistema complejo. Los ejem- 
plos incluyen sistemas que sufrirían cambios sustanciales en el tiempo, 
o sistemas en los cuales el procesamiento asociado con el flujo de 
datos no es necesariamente secuencial. 
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El análisis de las transformaciones es un conjunto de 
pasos de diseño que permite convertirun DED, con carac- 
terísticas de flujo de transformación, en un estilo arqui- 
tectónico específico. En esta sección se describeel análisis 
de las transformaciones aplicando los pasos de diseño a 
un sistema de, por ejemplo, una parte del software de 
Hogarseguro presentado en capítulos anteriores. 


14.6.1. Un ejemplo 


El sistema de seguridad Hogarseguro, presentado ante- 
riormente en este libro, es representativo de muchos 
productos y sistemas basados en computadora actual- 
mente en uso. El producto vigila el mundo real y reac- 
ciona ante cambios que encuentra. También interacciona 
con el usuario a través de una serie de entradas por tecla- 
do y visualizaciones alfanuméricas. El nivel O del dia- 
grama de flujo de datos de Hogarseguro, reproducido 
del Capítulo 12, se muestra en la Figura 14.5. 


Monitor 


Órdenes y datos Información del 
del usuario a visualizar panel 
de control 


Tipo 
de alarma 


Alarma 


Tonos 
Estado y 
del sensor la lleno pee 
e teléfono telefónica 


FIGURA 14.5. DFDa nivel de contexto para Hogarseguro. 


Durante el análisis de requisitos, se habrán creado 
más modelos detallados del flujo para Hogarseguro. 
Además, se crearán las especificaciones de control y 
proceso, un diccionario de datos y varios modelos de 
comportamiento. 


14.62.Pasos del diseño 


El ejemplo anterior se usará para ilustrar cada paso en 
el análisisde las transformaciones. Los pasos empiezan 
con una reevaluación del trabajo hecho durante el aná- 
lisis de requisitos y después evoluciona hacia el diseño 
de la arquitectura del software. 


Paso 1. Revisar el modelo fundamental del sis- 
tema. El modelo fundamental del sistema comprende 
el DFD de nivel O y la información que lo soporta. En 
realidad, el paso de diseño empieza con una evaluación 
de la especificación del sistema y de la especificación 
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de requisitos del software. Ambos documentos descri- 
ben el flujo y la estructura de la información en la inter- 
faz del software. Las Figuras 14.5 y 14.6 muestran el 
nivel O y 1 del flujo de datos del software Hogarseguro. 


Paso 2. Revisar y refinar los diagramas de flujo 
de datos del software. La información obtenida de los 
modelos de análisis contenidos en la Especificación de 
Requisitos del Software se refina para obtener mayor 
detalle. Por ejemplo, se examina el DFD del nivel 2 de 
monitorizar sensores (Fig. 14.7) y se obtiene un dia- 
grama de flujo de datos de nivel 3 como se muestra en 
la Figura 14.8. En el nivel 3, cada transformación en 
el diagrama de flujo de datos presenta una cohesión 
relativamente alta (Capítulo 13). Es decir, el proceso 
implicado por una transformación realiza una función 
única y distinta que puede implementarse como un 
módulo' en el software HogarSeguro. Por tanto, el DFD 
de la Figura 14.8 contiene suficiente detalle para esta- 
blecer un diseño «inicial» de la arquitectura del sub- 
sistema de monitorizar sensores y continuamos sin más 
refinamiento. 


Consuof) 


SielDFD es refinado más de uno vez, se esforzará por 
derivar burbujas que presentan gran cohesión. 


Paso 3. Determinar si el DFD tiene características 
de flujo de transformación o de transacción. En gene- 
ral, el flujo de información dentro de un sistema puede 
representarse siempre como una transformación. Sin 
embargo, cuando se encuentra una característica obvia 
de transacción (Fig. 14.4), se recomienda una estruc- 
tura de diseño diferente. En este paso, el diseñador selec- 
ciona la característica general del flujo (de la amplitud 
del software) basándose en la propia naturaleza del DFD. 
Además, se aíslan regiones locales de flujo de transfor- 
mación o de transacción. Estos subflujos pueden usarse 
para refinar la estructura del programa obtenida por la 
característica general que prevalece. Por ahora, con- 
centraremos nuestra atención solamente en el flujo de 
datos del subsistema de monitorización de sensores mos- 
trado en la Figura 14.7. 


YN 
Ss 


CLAVE 


A menudose podrán encontrar ambos tipos de flujo de 
datos dentro del mismo modelo de análisis. tos flujos se 
dividen y la estructura del programase deriva utilizando 
el análisis adecuado. 


9  Tautilización del término módulo en este capítulo equivale al tér- 
mino componente usado anteriormente en el estudio de la arquitec- 
tura de software. 


www.elsolucionario.net 


INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRACTICO 


Evaluando el DED (Fig. 14.8), vemos que los datos 
entran al software por un camino de entrada y salen por 
tres caminos de salida. No se distingue ningún centro 
de transacción (aunque la transformación establecer las 
condiciones de alarma podría percibirse como tal). Por 
tanto, se asumirá una característica general de transfor- 
mación para el flujo de información. 
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FIGURA 14.6. Nivel 1 del DFD del HogarSeguro. 


Paso 4. Aislar el centro de transformación especi- 
ficando los límites de los flujos de entrada y salida. 
En la sección precedente el flujo de entrada se describió 
como un camino en el que la información se convierte 
de formato externoen interno; el flujo de salida convierte 
de formato interno a externo. Los límites del flujo de 
entrada y el de salida son interpretables. Es decir, los 
diseñadores pueden elegir puntos ligeramente diferen- 
tes como límites de flujo. De hecho, se pueden obtener 
soluciones de diseño alternativas variando la posición 
de los límites de flujo. Aunque hay que tener cuidado 
cuando se seleccionan los límites, una variación de una 
burbuja a lo largo de un camino de flujo tendrá general- 
mente poco impacto en la estructura final del programa. 


Consuo 


Cambia lo situación de los fronteras de flujo en un 
esfuerzopor explorar los estructuras de programa 
alternafivas. No llevo mucho tiempo y puede 
proporcionamosimportantes ideas. 


Los límites de flujo del ejemplo se ilustran como cur- 
vas sombreadas que van verticales a través del flujo en 
la Figura 14.8. Las transformaciones(burbujas)que for- 
man el centro de transformación se encuentran entre los 
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dos límites sombreados que van de arriba abajo en el 
dibujo. Se podría argumentar algún cambio para rea- 
justar los límites (por ejemplo, se podría proponer un 
límite del flujo de entrada que separe leer sensores, de 
adquirir información de respuesta). El énfasis en este 
paso del diseño debería ponerse en seleccionar límites 
razonables, en vez de largas disquisicionessobre la colo- 
cación de las separaciones. 


Paso 5. Realizar una «descomposición de primer 
nivel», La estructura del programa representa una dis- 
tribución descendente del control. La descomposición 
en partes provoca una estructura de programa en la que 
los módulos del nivel superior realizan la toma de deci- 
siones y los módulos del nivel inferior realizan la mayo- 
ría del trabajo de entrada, cálculos y salida. Los módulos 
de nivel intermedio realizan algún control y cantidades 
moderadas de trabajo. 
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FIGURA 14.7. Nivel 2 del DFD que refina el proceso 
de monitorizar sensores 


Cuando encontramos un flujo de transformación, un 
DFD se organizaen una estructura específica (una arqui- 
tectura de llamada y retorno) que proporciona control 
para el procesamiento de información de entrada, trans- 
formación y de la salida. Esta descomposición en fac- 
tores O primer nivel del subsistema de monitorizar 
sensores se ilustra en la Figura 14.9.Un controlador 
principal, denominado gestor de monitorización de 
sensores, reside en la parte superior de la estructura del 
programa y sirve para coordinar las siguientes funcio- 
nes de control subordinadas: 


un controlador de procesamiento de la información de 
entrada denominado controlador de la entrada del sen- 
sor, coordina la recepción de todos los datos de entrada; 


un controlador del flujo de transformación, denomi- 
nado controladorde las condiciones de alarma, super- 
visa todas las operaciones sobre los datos en su forma 
interna (por ejemplo; un módulo que invoca varios 
procedimientos de transformación de datos); 
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FIGURA 14.8. Nivel 3 del DFD de monitorizar sensores con los límites de flujo. 


+ un controlador de procesamiento de información de 
salida, denominado controlador de la salida de alarma, 
coordina la producción de la información de salida. 


Cons) 


No seas dogmático en esta parte. Podría ser necesario 
establecer dos o más controladores de procesamiento de 
entrado o computación, acausa dela complejidad del 
sistema a construir. Si el sentido común asf te lo dicta, hazlo. 


v 


Aunque la Figura 14.9 implica una estructura con tres 
rates en grandes sistemas la complejidad del flujo puede 
hacer que existan dos o más módulos de control, uno para 
cada una de las funciones genéricas descritas anteriormente. 
El número de módulos del primer nivel debería limitarse 
al mínimo que pueda realizar las funciones de control 
y mantener al mismo tiempo unas buenas característi- 
cas de acoplamiento y cohesión. 


Paso 6. Realizar «descomposición de segundo 
niveb», La descomposición de segundo nivel se realiza 
mediante la conversión de las transformaciones indivi- 
duales (burbujas) de un DFD en los módulos corres- 
pondientes dentro de la arquitectura. Empezando desde 
el límite del centro de transformación y moviéndonos 


FIGURA 14.9. 
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hacia fuera a lo largo de los caminos de entrada, y luego 
de salida, las transformaciones se convierten en niveles 
subordinados de la estructura del software. El enfoque 
general del segundo nivel de descomposición del flujo 
de datos HogarSeguro se ilustra en la Figura 14.10. 


Aunque la Figura 14.10ilustra una correspondencia 
una a uno entre las transformaciones del DFD y los 
módulos del software, ocurren frecuentemente diferen- 
tes conversiones. Se pueden combinar dos o incluso tres 
burbujas y representarlas como un solo módulo 
(teniendopresente los problemas potenciales de la cohe- 
sión), o una sola burbuja puede dividirse en dos o más 
módulos. Las consideraciones prácticas y las medidas 
de la calidad dictan el resultado de la descomposición 
en factores de segundo nivel. La revisión y el refina- 
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miento pueden llevar a cambios en la estructura, pero 
puede servir como una primera iteración del diseño. 


Rionsuo) 


Mantén bajos los controladores de trabajo en la estructura 
del programa. Así, la arquitecturaserá más fácil de modificar. 


La descomposición de factores de segundo nivel del 
flujo de entrada sigue de igual manera. La descompo- 
sición en factores se realiza de nuevo moviéndose hacia 
fuera desde el límite del centro de transformación 
correspondiente al flujo de entrada. El centro de trans- 
formación del software del subsistema de monitorizar 
sensores se direcciona de manera algo diferente. Cada 
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FIGURA 14.10. Descomposición de factores de segundo nivel de monitorización de sensores. 
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conversión de datos o transformaciones de cálculo de 
la porción de transformación del DFD se convierte en 
un módulo subordinado al controlador de transforma- 
ción. En la Figura 14.11 se muestra una estructura de 
programa completa de primera iteración. 


Los módulos direccionados de la manera descrita 
anteriormente y mostrados en la Figura 14.11 repre- 
sentan un diseño inicial de la estructura del programa. 
Aunque los módulos se nombran de manera que indi- 
quen su función, se debería escribir para cada uno un 
breve texto que explique su procesamiento (adaptado 
del EP creado durante la modelación de análisis). El 
texto describe: 


+ la información que entra y la que sale fuera del 
módulo (una descripción de la interfaz); 

+ la información que es retenida en el módulo, por 
ejemplo, datos almacenados en una estructura de 
datos local; 

* una descripción procedimental que indique los prin- 
cipales puntos de decisión y las tareas; 

= un pequeño estudio de las restricciones y caracterís- 
ticas especiales (por ejemplo, archivo I/O, caracte- 
rísticas dependientes del hardware, requisitos 
especiales de tiempo). 


Cono 


Elimina los módulos de controlredundantes. Es decir, sí 
un módulo de controlno hace otro 00so que controlar 
otro módulo, estofunción de controldebería explotorse 
a mayor nivel, 


Gestor 
de la monitorización 
de sensores 


Controlador 
de las condiciones 
de alarma 


Controlador 
de la entrada 
del sensor 


Seleccionar 
el número 
de teléfono 


Establecer 
las condiciones 
de la alarma 


Obtener 
información 
de salida 


nsores 


wars aa wa 14 DISENO ARQUITECTÓNICO 


El texto explicativo sirve como una primera genera- 
ción de la especificaciónde diseño. Sin embargo, se dan 
más refinamientos y adicionesregularmente durante este 
periodo de diseño. 


Paso 7. Refinar la estructura inicial de la arquitec- 
tura usando heurísticas para mejorar la calidad del 
software. Una primera estructurade arquitectura siempre 
puede refinarse aplicando los conceptos de independen- 
ciade módulos (Capítulo 13). Los módulos se incremen- 
tano reducen para producir una descomposiciónrazonable, 
buena cohesión, acoplamiento mínimo y lo más impor- 
tante, una estructura que se pueda implementar sin difi- 
cultad, probarse sin confusión y mantenerse sinproblemas. 


Los refinamientos se rigen por el análisis y los méto- 
dos de evaluación descritos brevemente en la Sección 
14.4, así como por consideraciones prácticas y por el 
sentido común. Hay veces, por ejemplo, que el contro- 
lador del flujo de datos de entrada es totalmente inne- 
cesario, o se requiere cierto procesamiento de entrada 
en un módulo subordinado al controlador de transfor- 
mación, O no se puede evitar un alto acoplamiento 
debidoa datos generales,o no se pueden lograr las carac- 
terísticas estructurales óptimas (vea la Sección 13.6). 
Los requisitos del software junto con el buen juicio son 
los árbitros finales. 


Cons 


Céntreseen lo independencia funcional de los módulos 
que derive. Su objetivo debe ser uno cohesión alta 
y un acoplomiento débil 
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FIGURA 14.11. Primera iteración de la estructura del programa para monitorizar sensores. 


www.elsolucionario.net 


INGENIERÍA DEL SOFTWARE. Un ENFUQUE FKAUILICU 


Se pueden hacer muchas modificaciones a la primera 
estructura desarrollada para el subsistema de monitori- 
zar sensores de HogarSeguro. Algunas de ellas son: 

1. El controlador del flujo de entrada se puede elimi- 
nar porque es innecesariocuando sólo hay que mane- 
jar un solo camino de flujo de entrada. 


. La subestructura generada del flujo de transforma- 
ción puede reducirse en el módulo establecer las 
condiciones de alarma (que incluirá ahora el pro- 
cesamiento implicado por seleccionar número de 
teléfono). El controlador de transformación no será 
necesario y la pequeña disminución en la cohesión 
es tolerable. 

. Los módulos dar formato de visualización y gene- 
rar la visualización pueden unirse (asumimosque dar 
formato de visualización es bastante simple) en un 
nuevo módulo denominado producir visualización. 


En la Figura 14.12 se muestra la estructura del soft- 
ware refinada del subsistema de monitorizar sensores. 


El objetivo de los siete puntos anteriores es desarro- 
llar una representación general del software. Es decir, 
una vez que se ha definido la estructura, podemos eva- 
luar y refinar la arquitectura del software viéndola en 
su conjunto. Las modificaciones hechas ahora requie- 
ren poco trabajo adicional, pero pueden tener un gran 
impacto en la calidad del software. 


El lector debería reflexionar un momento y consi- 
derar la diferencia entre el enfoque de diseño descri- 
to anteriormente y el proceso de «escribir programas)). 
Si el código es la única representación del software, 
el desarrollador tendrá grandes dificultades en eva- 
luar o refinar a nivel general u holístico y, de hecho, 
tendrá dificultad para que «los árboles dejen ver el 
bosque». 


En muchas aplicaciones software, un solo elemento de 
datos inicia uno o varios de los flujos de información 
que llevan a cabo una función derivada por el elemento 
de datos iniciador. El elemento de datos, denominado 
transacción, y sus características de flujo correspon- 
dientes se trataron en la Sección 14.5.2. En esta sec- 
ción consideramos los pasos de diseño usados para 


tratar el flujo de transacción. 
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FIGURA 14.12. Estructura refinada del programa 
para monitorizar sensores. 


14.71. Un ejemplo 


El análisis de las transacciones se ilustrará conside- 
rando el subsistema de interacción con el usuario del 
software HogarSeguro. El nivel 1 del flujo de datos de 
este subsistema se muestra como parte de la Figura 
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14.6. Refinando el flujo, se desarrolla un nivel 2 del 
diagrama de flujo (también se crearían un diccionario 
de datos correspondiente, EC y EP) que se muestra en 
la Figura 14.13. 

Como se muestra en la figura, Ordenes y datos del 
usuario fluye al sistema y provoca un flujo de infor- 
mación adicional a lo largo de uno de tres caminos de 
acción. Un elemento de datos, tipo de orden, hace que 
el flujo de datos se expanda del centro. Por tanto, la 
característica general del flujo de datos es de tipo tran- 
sacción. 

Debería recalcarse que el flujo de información a lo 
largo de dos de los tres caminos de acción acomodan 
flujos de entrada adicionales (por ejemplo, parámetros 
y datos del sistema son entradas en el camino de acción 
a «configurar»). Todos los caminos de acción fluyen a 
una sola transformación, mostrar mensajes y estado. 


14.7.2. Pasos del diseño 


Los pasos del diseño para el análisis de las transaccio- 
nes son similares y en algunos casos idénticos a los pasos 
para el análisis de las transformaciones (Sección 14.6). 
La principal diferencia estribaen la conversión del DFD 
en la estructura del software. 


Paso 1. Revisar el modelo fundamental del sis- 
tema. 


Paso 2. Revisar y refinar los diagramas de flujo de 
datos para el software. 


Paso 3. Determinar si el DFD tiene características 
de flujo de transformación o de transacción. Los pasos 
1,2 y 3 son idénticos a los correspondientes pasos del 
análisis de las transformaciones. El DFD mostrado en la 
Figura 14.13 tiene la clásica característicade flujo de tran- 
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FIGURA 14.13. Nivel 2 de DFD para el subsistema de interación del usuario con límites del flujo. 


sacción. Sin embargo, el flujo a lo largo de dos de los 
caminos de acción que emanan desde la burbuja invocar 
elprocesamiento de la orden parece tener características 
de flujo de transformación. Por tanto, se deben estable- 
cer los límites de flujo para ambos tipos de flujos. 


Paso 4. Identificar el centro de transacción y las 
características de flujo a lo largo de cada camino de 
acción. La posición transacción se puede discernir inme- 
diatamente del DFD. El centro de transacción está en el 
origen de varios caminos de acción que fluyen radial- 
mente desde él. Para el flujo mostrado en la Figura 14.13, 
la burbuja invocar el procesamiento de la orden es el 
centro de transacción. 


El camino de entrada (por ejemplo el camino de flujo 
a lo largo del que se recibe una transacción) y todos los 
caminos de acción deben aislarse. Los límites que definen 
un camino de recepción y los caminos de acción también 
se muestran en la figura. Se debe evaluar las característi- 
cas individuales de flujo de cada camino de acción. Por 
ejemplo, el camino «de la contraseña» (mostradoincluido 
en un área sombreada en la Fig. 14.13) tiene característi- 
cas de transformación. Los flujos de entrada, de transfor- 
mación y de salida se indican con límites. 


Paso 5. Transformar el DFD en una estructura de 
programa adecuada al procesamiento de la tran- 
sacción. El flujo de transacción se convierte en una 
arquitectura que contiene una rama de entrada y una 
rama de distribución. La estructurade la rama de entrada 
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se desarrolla de la misma manera que para un análisis 
de transformación. Empezando por el centro de tran- 
sacción, las burbujas que hay a lo largo del camino de 
entrada se convierten en módulos. La estructura de la 
rama de distribución contiene un módulo distribuidor 
que controla todos los módulos de acción subordina- 
dos. Cada camino de flujo de acción del DFD se con- 
vierte en una estructura que corresponde a sus 
características específicas de flujo. Este proceso se ilus- 
tra esquemáticamente en la Figura 14.14. 


NN 
“ 
la descomposiciónde primer nivel tiene como resultado 
lo derivación de la jerarquía de control poro el software. 


lo descomposición de segundo nivel distribuye los 
módulos de trabajo a los aaniraiodares opropiodos. 


Considerandoel flujo de datos del subsistemade infe- 
racción del usuario, la descomposición de primer nivel 
del paso 3 se muestra en la Figura 14.15. Las burbujas 
leer órdenes del usuario y activarldesactivar el sistema 
se convierten directamente en la arquitectura, sin la nece- 
sidad de módulos intermedios de control. El centro de 
transacción, invocar el procesamiento de la orden, se 
convierte directamente en un módulo distribuidor con 
el mismo nombre. Los controladores de la configura- 
ción del sistema y procesamiento de la contraseña se 
obtienen como se indica en la Figura 14.16. 
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FIGURA 14.14. Análisis de transacción. 
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FIGURA 14.15. Descomposición en factores de primer nivel 
del subsistema interacción del usuario. 
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FIGURA 14.16. Primera iteración de la estructura del programa del subsictema interacción del usuario. 
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Paso 6. Descomponer y refinar la estructura de 
transacción y la estructura de todos los caminos de 
acción. Cada camino de acción del diagrama de flujo 
de datos tiene sus propias características de flujo de 
información. Ya hemos dicho anteriormente que se 
pueden encontrar flujos de transformación o de tran- 
sacción. La «subestructura» relacionada con el camino 
de acción se desarrolla usando los pasos estudiados 
en esta sección y en la anterior. 


Por ejemplo, considere el flujo de información del 
procesamiento de contraseña mostrado (dentro del 
área sombreada) en la Figura 14.13.El flujo presenta 
las característicasclásicas de transformación. Se intro- 
duce una contraseña (flujo de entrada) y se transmite 
aun centro de transformación donde se compara con 
las contraseñas almacenadas. Se produce una alarma 
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y un mensaje de advertencia (flujo de salida) si no 
coincide con ninguna. 


El camino «configurar» se dibuja similarmente 
usando el análisis de transformación. La arquitectura de 
software resultante se muestra en la Figura 14.16. 


Paso 7. Refinar la primera arquitectura del pro- 
grama usando heurísticas de diseño para mejorar la 
calidad del software. Este paso del análisis de tran- 
sacción es idéntico al correspondiente paso del análisis 
de transformación. 


En ambos métodos de diseño se deben considerar cui- 
dadosamente criterios tales como independencia del 
módulo, conveniencia (eficacia de implementación y 
prueba) y facilidad de mantenimiento a medida que se 
proponen modificaciones estructurales. 


El éxito de la aplicación del análisis de transformación o 
de transacción se complementaañadiendo la documenta- 
ción adicional requerida como parte del diseño arquitec- 
tónico. Después de haber desarrollado y refinado la 
estructura, se deben completarlas siguientes tareas: 


se debe desarrollaruna descripción del procesamiento 
para cada módulo. 

se aporta una descripción de la interfaz para cada 
módulo. 

se definen las estructuras de datos generales y locales. 
se anotan todas las limitaciones/restricciones del 
diseño. 

se lleva a cabo una revisión del diseño. 

se consideraun «refinamiento»(si es necesario y está 
justificado). 


Un texto explicativo del procesamiento es (ideal- 
mente) una delimitada descripción sin ambigitedades 
del procesamientoque ocurre dentro de un módulo. La 
narrativa describe el procesamiento, las tareas, las deci- 
siones y la entrada/salida. La descripción de la interfaz 
requiere el diseño de interfaces internas de módulo, 
interfaces externas del sistema y la interfaz hombre- 
computadora (Capítulo 15).El diseño de estructuras de 
datos puede tener un profundo impacto en la arquitec- 
tura y en los detalles procedimentales de cada compo- 
nente del software. También se documentan las 
restricciones/limitaciones de cada módulo. Algunos 
aspectos típicos que pueden tratarse incluyen: la res- 
tricción de tipo o formato de datos, las limitaciones de 


¿Qué pasa una vez que 
la arquitectura ha sido creada? 
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memoria o de tiempo, la delimitación de los valores o 
cantidades de las estructuras de datos, los casos espe- 
ciales no considerados y las características específicas 
de un módulo individual. El propósito de una sección 
restricciones/limitaciones es reducir el número de erro- 
res debidos a características funcionales asumidas. 
Una vez que se ha desarrollado la documentación de 
diseño para todos los módulos, se lleva a cabouna revisión 
(vea las directrices de revisión en el Capítulo 8). La revi- 
sión hace hincapié en el seguimiento de los requisitos del 


software, 1, Calidad ¿e 1a arquitectura del programa, las Y 


es” 
cripciones Ye las interfaces. las descripciones delas estruc- 
turas de datos, los datos prácticos de la implementación,la 
capacidad de prueba y la facilidad de mantenimiento. 


Documento del diseño de software. 


Debe fomentarse el refinamiento de la arquitectura 
del software durante las primeras etapas del diseño. 
Como ya dijimos anteriormente en este capítulo, los 
estilos arquitectónicos alternativos deben ser derivados, 
refinados y evaluados para un «mejor» enfoque. Este 
enfoque de optimización es uno de los verdaderos bene- 
ficios derivados del desarrollo de la representación de 
la arquitectura del software. 

Es importante anotar que la simplicidadestructural es, 
a menudo, reflejo de eleganciay eficiencia. El refinamiento 
del diseño debería luchar por obtener un pequeño núme- 
ro de módulos consecuentes a la modularidad operativa 
y la estructura de datos menos compleja que sirva ade- 
cuadamentea los requisitos de información. 
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INGENIERÍA DEL SOFTWARE. Ll. 2 


La arquitecturadel softwarenos proporciona una visión 
global del sistema a construir. Describe la estructura y 
la organización de los componentes del software, sus 
propiedades y las conexiones entre ellos. Los compo- 
nentes del software incluyen módulos de programas y 
varias representaciones de datos que son manipulados 
por el programa. Además, el diseño de datos es una par- 
te integral para la derivación de la arquitectura del soft- 
ware. La arquitectura marca decisiones de diseño 
tempranas y proporcionael mecanismo para evaluar los 
beneficios de las estructuras de sistema alternativas. 

El diseño de datos traduce los objetos de datos defi- 
nidos en el modelo de análisis, en estructuras de datos 
que residen dentro del software. Los atributos que des- 
cribe el objeto, las relaciones entre los objetos de datos 
y su uso dentro del programa influyen en la elección de 
la estructura de datos. A mayor nivel de abstracción, el 
diseño de datos conducirá a lo que se define como una 
arquitectura para una base de datos o un almacén de datos. 

El ingeniero del software cuenta con diferentes esti- 
los y patrones arquitectónicos. Cada estilo describe una 
categoría de sistema que abarca un conjunto de com- 
ponentes que realizan una función requerida por el sis- 
tema, un conjunto de conectores que posibilitan la 
comunicación, la coordinación y cooperación entre los 
componentes, las restricciones que definen cómo se inte- 
gran los componentes para conformar el sistema, y los 
modelos semánticos que facilitan al diseñador el enten- 
dimiento de todas las partes del sistema. 

Han sido propuestos uno o varios estilos arquitectó- 
nicos por sistema, y el método de análisis de compro- 
misos para la arquitectura podría utilizarse para evaluar 


la eficacia de cada arquitectura propuesta. Esto se con- 
sigue determinando la sensibilidad de los atributos de 
calidad seleccionados (también llamados dimensiones 
del diseño) con diferentes mecanismos de realización 
que reflejan las propiedades de la arquitectura. 

El método de diseño arquitectónico presentado en 
este capítulo utiliza las características del flujo de datos 
descritasen el modelo de análisis que derivan de un esti- 
lo arquitectónico utilizado comúnmente. El diagrama 
de flujo de datos se descompone dentro de la estructu- 
ra del sistema a través de dos enfoques de análisis —el 
análisis de las transformaciones y/o el análisis de las 
transacciones —. Se aplica el análisis de las transfor- 
maciones a un flujo de información que presenta dife- 
rentes límites entre los datos de entrada y de salida. El 
DFD se organiza en una estructura que asigna los con- 
troles de entrada, procesamiento y salida a través de tres 
jerarquías separadas de módulos de descomposición en 
factores. El análisis de las transformaciones se aplica 
cuando un Único ítem de información bifurca su flujo a 
través de diferentes caminos. El DFD se organiza en 
una estructura que asigna el control a una subestructu- 
ra que adquiere y evalúa la transacción. Otra subes- 
tructura controla todas las acciones potenciales de 
procesamiento basadas en la transacción. Una vez que 
la arquitectura ha sido perfilada se elabora y se analiza 
contrastándola con los criterios de calidad. 

El diseño arquitectónico agrupa un grupo inicial de 
actividades de diseño que conducen a un modelo com- 
pleto del diseño del software. En los siguientes capítu- 
los, se estudiará el diseño de las interfaces y de los 
componentes. 


[AHO83] Aho, A.V., J, Hopcroft y J.Ullmann, Data Structu- 
res and Algorithms, Addison-Wesley, 1983. 


[BAS98] Bass, L., P. Clements y R. Kazman, Software Archi- 
tecture in Practice, Addison-Wesley, 1998. 


[DAH72] Dah, O., E. Dijkstra y C, Hoare, Structured Pro- 
gramming, Academic Press, 1972. 


[DAT95] Date, C.J., An Introduction to Database Systems, 
Sexta Edición, Addison-Wesley, 1995. 


[DEN73] Dennis, J.B., «Modularity», en Advanced Course 
on Software Engineering, F,L. Bauer (ed.), Springer-Ver- 
lag, Nueva York, 1973,pp. 128-182. 

[FRE380] Freeman, P., «The Context af Design», in Software 


Design Techniques (L.P. Freeman y A. Wasserman, eds.), 
TEEE Computer Society Press, 3.”ed., 1980, pp. 2-4. 


[INM95] Inmon, W.H., «What is a Data Warehouse?» Prism 
Solutions, Inc. 1995, presentada en: 
http://www.cait.wustl.edu/cait/papers/prism/voll_nol. 
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[KAZ98] Kazman, R. The Architectural Tradeoff Analysis 
Method, Software Engineering Institute, CMU/SEI-98- 
TR-008. Julio 1998. 


[KIM98] Kimball, R., L, Reeves, M. Ross y W. Thornthwai- 
te, The Data WarehouseLifecycle Toolkit: Expert Methods 
for Designing, Developing, and Deploying, Data Ware- 
houses, Willey, 1998. 


[LIN79] Linger, R.C., H.D. Mills y B.I. Witt, StructuredPro- 
gramming, Addison-Wesley, 1979. 


[MAT96] Mattison, R., Data Warehousing: Strategies, Tech- 
nologies and Techniques, McGraw-Hill, 1996. 


[MOR80] Morris, J., «Programming by Successive Refine- 
ment of Data Abstractions», Software-Practice and Expe- 
rience, vol. 10,núm. 4, abril 1980, pp. 249-263. 


[MYE78] Myers, G., Composite Structures Design, Van- 
Nostrand, 1978. 
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[PET81] Peters, L.J., Software Design: Methods and Techni- 
ques, Yourdon Press, Nueva York, 1981, 


[PRE98] Preiss, B.R. Data Structures and Algorithms: With 
Ohject-Oriented Design Patterns in C++, Wiley, 1998. 

[SHA96] Shaw, M., y D. Garlan, Software Arquitecture, Pren- 
tice Hall, 1996. 

[SHA97] Shaw, M., y P. Clements, «A Field Guide to Boxo- 
logy: Preliminary Classification of Architectural Styles for 
Software Systems», Proc. COMPSAC, Washington DC, 
Agosto 1997, 


[STE74] Stevens, W., G. Myers y L. Constantine, «Structu- 
red Design», IBM System Journal, vol.13,n.* 2, 1974, 
pp. 115-139, 


GArIuLO 14 DISEÑO ARQUITECTÓNICO 


[WAS80] Wasserman, A., «Principles of Systematic Data 
Design and Implementation», en Software Design Tech- 
niques (P. Freeman y A. Wasserman, eds.), 3.* ed., IEEE 
Computer Society Press, 1980, pp. 287-293. 


[WIR71] Wirth, N., «Program Development by Stepwise Refi- 
nement», CACM, vol. 14,n.* 4, 1971, pp. 221-227. 


[Y0U79] Yourdon, E., y L. Constantine, Structures Design, 
Prentice-Hall, 1979. 


[ZHA98] Zhao, J., «On Assessing the Complexity of Soft- 
ware Architectures», Proc. Intl. Software Architecture 
Workshop, ACM, Orlando, Florida, 1998, pp. 163-167. 


141. Usando la arquitectura de una casa o un edificio a modo 
de metáfora, dibuje comparaciones con la arquitectura del 
software. ¿En qué se parecen la disciplina de la arquitectura 
clásica y la de la arquitectura del software? ¿En qué se dife- 
rencian? 


14.2, Escriba un documento de tres a cinco páginas que con- 
tenga directrices para la selección de estructuras de datos 
basándose en la naturaleza del problema. Empiece delimi- 
tando las clásicas estructuras de datos que se encuentran en 
el software y después describiendo los criterios para la selec- 
ción de éstos para tipos particulares de problemas. 


14,3. Explique la diferencia entre una base de datos que sir- 
ve auna O más aplicaciones de negocios convencionales y un 
almacén de datos. 


14.4. Escriba un documento de tres a cinco página que des- 
criba cómo se utilizan las técnicas de minería de datos en 
un entorno de negocio y el estado actual de las técnicas 
DCEC. 


14,5. Presente dos o tres ejemplos de aplicaciones para cada 
estilo arquitectónico citado en la Sección 14.3.1. 


14.6. Algunos de los estilos arquitectónicos citados en la Sec- 
ción 14.3.1.sonjerárquicos por naturaleza y otros no. Haga 
una lista de cada tipo. ¿Cómo se implementanlos estilos arqui- 
tectónicos no jerárquicos? 


14,7, Seleccione una aplicación que le sea familiar. Contes- 
tecada una de las preguntas propuestas para el control y los 
datos de la Sección 14.3.2, 


14.8. Estudie el MACA (utilizando el libro de [KKAZ98]) y 
presente un estudio detallado de los seis pasos presentados 
* enla Sección 14.4.1. 


149, Seleccione una aplicación que le sea familiar. Utili- 
* zando, donde sea requerido, su mejor intuición, identifique 
* el conjunto de dimensiones del diseño y después realice el 
- análisis del espectro y el análisis de la selección del diseño. 


14,10. Estudie el EDC (utilizando el libro de [SHA96]) y 
* desarrolle un espacio de diseño cuantificado para una aplica- 
ción que le sea familiar. 
14.11. Algunos diseñadores defienden que todo el flujo de 
, datos debe ser tratado como orientado a transformaciones. 
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Estudie como afectará esta opinión a la estructura del soft- 
ware que se obtiene cuando un flujo orientado a transacción 
es tratado como de transformación. Utilice un flujo de ejem- 
plo para ilustrar los puntos importantes. 


14.12. Sino lo ha hecho, complete el Problema 12.12. Utili- 
ce los métodos de diseño descritos en este capítulo para desa- 
rrollar una estructura de programa para el SSRB. 


14.13. Mediante un diagrama de flujo de datos y una des- 
cripción del procesamiento, describa un sistema basado en 
computadora que tenga unas características de flujo de trans- 
formación singulares. Defina los límites del flujo y transfor- 
me el DFD en la estructura software usando una técnica de las 
descritas en la Sección 14.6. 


14.14. Mediante un diagrama de flujo de datos y una des- 
cripción de procesamiento, describa un sistema basado en 
computadora que tenga unas características de flujo de tran- 
sacción claras. Defina los límites del flujo y direcciones el 
DFD en una estructura software utilizando la técnica descri- 
ta en la Sección 14.7. 


14.15. Usando los requisitos obtenidos en un estudio hecho 
en clase, complete los DFD y el diseño arquitectónico para el 
ejemplo HogarSeguro presentadoen las Secciones 14.6 y 14.7. 
Valore la independenciafuncionalde todos los módulos. Docu- 
mente su diseño. 


14.16. Estudie las ventajas y dificultades relativas de aplicar 
un diseño orientado al flujo de datos en las siguientes áreas: 
(a) aplicaciones de microprocesador empotrado, (b) análisis 
de ingeniería/científico, (c) gráficos por computadora, (d) dise- 
ño de sistemasoperativos, (e) aplicacionesde negocio, (f) dise- 
ño de sistemas de gestión de bases de datos, (g) diseño de 
software de comunicaciones, (h) diseño de compiladores, (1) 
aplicaciones de control de proceso y (J) aplicaciones de inte- 
ligencia artificial. 


14.17. Dado un conjunto de requisitos que le proporcione 
su profesor (o un conjunto de requisitos de un problema en 
el que esté trabajando actualmente) desarrolle un diseño 
arquitectónico completo. Lleve a cabo una revisión del dise- 
ño (Capítulo 8) para valorar la calidad de su diseño. Este pro- 
blema debe asignarse a un equipo en vez de a un solo 
individuo. 
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INGENIERÍA DEL SOFTWARE. Un ENFUQUE PHACTICO 


Durante la Última década han aparecido muchísimos libros 
sobre arquitectura de software. Los libros de Shaw y Gannon 
[SHA96], Bass, Clements y Kazman [BAS98] y Buschmann 
y colaboradores[BUS98], proporcionan un tratamiento en 
profundidad sobre la materia. El primer trabajo de Garlan (An 
Introduction to Software Architecture, Software Engineering 
Institute, CMU/SEI-94-TR-02 1,1994) proporciona una exce- 
lente introducción al tema. 

Los libros específicos de implementación de arquitectu- 
ra, sitúan el diseño arquitectónico dentro de un entorno espe- 
cífico de desarrollo o tecnología. Mowray (CORBA Design 
Patterns, Wiley, 1997) y Mark y colaboradores(ObjectMana- 
gement Architecture Guide, Wiley, 1996) proporcionan pará- 
metros de diseño detallados para el marco de soporte de las 
aplicaciones distribuidas de CORBA. Shanley (Protected 
Mode Software Architecture, Addison-Wesley, 1996) pro- 
porciona una guía de diseño arquitectónico para aquellos que 
diseñen sistemas operativos a tiempo real basados en com- 
putadora, sistemas operativos multitarea o controladores de 
dispositivos. 

Las investigaciones actuales sobre arquitectura de soft- 
ware están recogidas en el anuario Proceedings of the Inter- 
national Workshopon Software Architecture, patrocinado por 
la ACM y otras organizaciones de computadoras y en el Pro- 
ceedings of the International Conference on Software Engi- 
neering. 

El modelado de datos es un prerrequisito para un buen 
diseño de datos. Los libros de Teory (Database Modeling 
£ Design, Academic Press, 1998), Schimdt (Data Modeling 

for Information Professionals, Prentice Hall, 1998), Bobak, 
(Data Modeling and Design for Today's Architectures, 
Artech House, 1997), Silverston, Graziano e Inmon (The 
Data Model Resource Book, Wiley, 1997), Date [DAT95], 
Reingruber y Gregory (The Data Modeling Handbook: A 
Best-Practice Approach to Building Quality Data Models, 
Wiley, 1994), Hay (Data Model Patterns: Conventions of 
Thought, Dorset House, 1994) contienen una presentación 
detallada de la notación de modelado de datos, heurísticas, 
y enfoques de diseño de bases de datos. En los últimos años 
el diseño de almacenes de datos ha ido cobrando importan- 
cia. Los libros de Humphreys, Hawkins y Dy (Data Ware- 
housing: Architecture and Implementation, Prentice Hall, 
1999), Kimball [KIM98] e Inmon [INM95] cubren con gran 
detalle la materia. 
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Docenas de libros actuales, a menudo abordan el diseño 
de datos y el diseño de estructuras desde un contexto especí- 
fico del lenguaje de programación. Algunos ejemplos típicos 
los encontramos en: 


Horowitz, E. Y S. Sahni, Fundamentals o£Data Structures 
in Pascal, 4.* ed., W.H. Freeman é; Co., 1999. 


Kingston, J.H., Algorithms and Data Structures: Design, 
Correctness,Analysis, 2.* ed., Addison-Wesley, 1997. 


Main, M., Data Structures £ Other Objects Using Java, 
Addison-Wesley, 1998. 

Preiss, B.R., Data Structures and Algorithms: With Object- 
Oriented Design Patterns in C++, Wiley, 1998. 

Sedgewick,R., Algorithms in C++: Fundamentals, Data 
Structures, Sorting, Searching, Addison-Wesley, 1999. 

Standish, T.A., Data Structures in Java, Addison-Wesley, 
1997. 

Standish,T.A., Data Structures, A !gorithms, and Sofiware 
Principles in C, Addison-Wesley, 1995. 


En la mayoría de los libros dedicados a la ingeniería de soft- 
ware se puede encontrar un tratamiento general del diseño del 
software en discusión con el diseño arquitectónicoy el diseño 
de datos. Los libros de Pfleeger (SoftwareEngineering: Theory 
and Practice, Prentice may, 1998) y Sommerville (Software 
Engineering, 5." ed., Addison-Wesley, 1995) son representati- 
vos de los libros que cubren en detalle el tema del diseño. 

Se puede encontrarun tratamientomás rigurosode la mate- 
ria en Feijs (Formalizationof Design Methods, Prentice may, 
1993), Witt y colaboradores (SoftwareArchitecture and Design 
Principles, Thomson Publishing, 1994) y Budgen (Software 
Design, Addison-Wesley, 1994). 

Se pueden encontrar representaciones completas de dise- 
ños orientados a flujos de datos en Myers [MYE78], Yourdon 
y Constantine[YOU79], Buhr (SystemDesign withA da, Pren- 
tice may, 1984), y Page-Jones (The Practical Guide to Struc- 
tured Systems Design, segunda edición, Prentice may, 1988). 
Estos libros están dedicados solamente al diseño y propor- 
cionan unas completas tutorías en el enfoque de flujo de datos. 

En Intemet están disponibles una gran variedad de fuen- 
tes de información sobre diseño de software y temas relacio- 
nados. Una lista actualizada de referencias web sobre 
conceptos y métodos de diseño relevantes se puede encon- 
trar en: http://www.pressman5.com. 
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CAPÍTULO 


15 


DISEÑO DE LA INTERFAZ 
DE USUARIO 


L plano de una casa (su diseño arquitectónico) no está completo sin la representación de 
Eg ventanas y conexiones de servicios para el agua, electricidad y teléfono (por no 

mencionar la televisión por cable). Las «puertas, ventanas y conexiones de servicios» 
del software informático es lo que constituye el diseño de la interfaz de usuario. 

El diseño de la interfaz se centra en tres áreas de interés: (1) el diseño de la interfaz entre los 
componentes del software; (2) el diseño de las interfaces entre el software y los otros produc- 
tores y consumidores de información no humanos (esto es, otras entidades externas) y (3) el 
diseño de la interfaz entre el hombre (esto es, el usuario) y la computadora. En este capítulo 
nos centraremos exclusivamente en la tercera categoría de diseño de interfaz —el diseño de la 
interfaz de usuario—. 

Ben Shneiderman [SHN87] habla sobre esta categoría de diseño en el prólogo de su libro y 
afirma lo siguiente: 


Para muchos usuarios de sistemas de información computerizadosla frustración y la ansiedad forman 
parte de su vida diaria. Luchan por aprender el lenguaje de órdenes y los sistemas de selección de menús 
que supuestamente les ayudan a realizar su trabajo. Algunas personas se encuentran con casos tan serios 
de shocks informáticos, terror en el terminal o neurosis en la red, que evitan utilizar sistemas computeri> 
zados. 


VISTAZO RÁPIDO 


maria de la po 


leas es lá que de da. ala percep- 
ción del software por parte del usuario, 
tiene que estar bien diseñada. 


¿Cuáles son los pasos? El diseño de la 
interfaz de usuario comienza con la 
identificación de los requisitos del usua- 
rio, de la tarea y del entorno. Una vez: 


ño identifica los Ed y acciones 

la interfaz y crea entonces un forma- 

to de pantalla que formará la base del 
prototipo de interfaz de úsuario. 


¡Quién lo hace? El ingeniero del software 


es quien diseña la interfaz de usuario 
mediante la aplicación del proceso ite- 
rativo ) que se sirve de los principios pre- 


identificadas las tareas, se crean y se : 


“amalizan los escenarios del usuario para. 


definir el conjunto de objetos y de accio- 


, O causa frústrición para conse- 
guir los objetivos, 


nes de la interfaz. Esto es lo que forma 
la base para la creación del formato 

la pantalla que representa el diseño grá-. 
fico y la colocación de iconos, la defini- 


no será de agrado, ción del texto descriptivo en pantalla, 


Los problemas a los que alude Shneiderman son reales. Es cierto que las interfaces gráficas, 
ventanas, iconos y selecciones mediante ratón han eliminado muchos de los terribles proble- 
mas con la interfaz. Pero incluso en un «mundo de ventanas» todos encontramos interfaces de 
usuario difíciles de aprender, difíciles de utilizar, confusas, imperdonables y en muchos casos 
totalmente frustrantes. Sin embargo, hay quien dedica tiempo y energías construyendo estas 
interfaces, y es posible que estos problemas no los crearan a propósito. 
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INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRÁCTICO 


Theo Mantel [MAN97] en su libro crea tres «reglas de 
oro» para el diseño de la interfaz: 


1, Darel control al usuario 
2. Reducir la carga de memoria del usuario 
3. Construir una interfaz consecuente 


Estas reglas de oro forman en realidad la base para 
los principios del diseño de la interfaz de usuario que 
servirán de guía para esta actividad de diseño de soft- 
ware tan importante. 


15.1.1. Dar el control al usuario 


Durante la sesión de recopilación de los requisitos para 
un nuevo sistema de información, un usuario clave fue 
preguntado a cerca de los atributos de la interfaz gráfi- 
ca orientada a ventanas. 

El usuario respondió solemnemente, «Lo que me gus- 
taría realmente es un sistema que lea mi mente. Que 
conozca lo que quiero hacer antes de necesitarlo y que 
me facilite hacerlo. Eso es todo. Simplemente eso.» 

Mi primera reacción fue mover la cabeza y sonreír, 
y hacer una pausa por unos instantes. No había nada 
malo en la solicitud del usuario. Lo que quería era que 
un sistema reaccionara ante sus necesidades y que le 
ayudara a hacer las cosas. Quería controlar la compu- 
tadora, y no dejar que la computadora le controlara. 

La mayor parte de las restricciones y limitaciones 
impuestas por el diseñador se han pensado para sim- 
plificar el modo de interacción. Pero, ¿para quienes? En 
muchos casos es posible que el diseñador introduzca 
limitaciones y restricciones para simplificar la imple- 
mentación de la interfaz. Y el resultado puede ser una 
interfaz fácil de construir, pero frustrante de utilizar. 

Mandel [MAN97] define una serie de principios de 
diseño que permiten dar control al usuario: 


Definir los modos de interacción de manera que no 
obligue a que el usuario realice acciones innecesarias 
y no deseadas. Un modo de interacción es el estado 
actual de la interfaz. Por ejemplo, si en el procesador 
de textos se selecciona el corrector ortográfico, el 
software pasa a modo corrector ortográfico. No hay 
ninguna razón por la que obligar a que el usuario 
permanezca en este modo si el usuario desea continuar 
editando una parte pequeña de texto. El usuario deberá 
tener la posibilidad de entrar y salir de este modo sin 
mucho o ningún esfuerzo. 


¿Cómo se diseñan interfaces 
que den el control al usuario? 


Tener en consideración una interacciónflexible. Dado 
que diferentes usuarios tienen preferencias de interacción 
diferentes, se deberán proporcionar diferentes selecciones. 
Por ejemplo, un software que pueda permitir al usuario 
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interactuar a través de las órdenes del teclado, con el 
movimiento del ratón, con un lápiz digitalizador, mediante 
órdenes para el reconocimiento de voz. Sin embargo, no 
toda acción responde a todo mecanismo de interacción. 
Considere por ejemplo, la dificultad de utilizar órdenes 
del teclado (o entrada de voz) para dibujar una forma 
compleja. 

Permitir que la interacción del usuario se pueda 
interrumpir y deshacer. Cuando un usuario se ve 
involucrado en una secuenciade acciones, deberá poder 
interrumpir la secuencia para hacer cualquier otra cosa 
(sin perder el trabajo que se hubiera hecho anteriormente). 
El usuario deberá también tener la posibilidad de 
«deshacer» cualquier acción. 


Aligerar la interacción a medida que avanza el nivel 
de conocimiento y permitir personalizar la interacción. 
El usuario a menudo se encuentra haciendo la misma 
secuencia de interacciones de manera repetida. Merece 
la pena señalar un mecanismo de «macros» que 
posibilite al usuario personalizarla interfaz y así facilitar 
la interacción. 


errores mús comunes que se comete 
diseñar algo a prueba de tontos 
idod de los tontos. 


Ocultar al usuario ocasional los entresijos técnicos. 
La interfaz de usuario deberá introducir al usuario en el 
mundo virtual de la aplicación. El usuario no tiene que 
conocer el sistema operativo, las funciones de gestión 
de archivos, O cualquier otro secreto de la tecnología 
informática. Esencialmente, la interfaz no deberá 
requerir nunca que el usuario interactúe a un nivel 
«interno» de la máquina (por ejemplo, el usuario no 
tendrá que teclear nunca las órdenes del sistema 
operativo desde dentro del software de aplicación). 


Diseñar la interacción directa con los objetos que 
aparecen en la pantalla. El usuario tiene un sentimiento 
de control cuando manipula los objetos necesarios para 
llevar a cabo una tarea de forma similar a lo que ocurriría 
si el objeto fuera algo físico. Como ejemplo de 
manipulación directapuede ser una interfaz de aplicación 
que permita al usuario «alargar» un objeto (cambiar su 
tamaño). 


15.1.2. Reducirla carga de memoria del usuario 


Cuanto más tenga que recordar un usuario, más propen- 
sa a errores será su interacción con el sistema. Esta es la 
razón por la que una interfaz de usuario bien diseñada no 
pondrá a prueba la memoria del usuario. Siempreque sea 
posible, el sistemadeberá «recordar»la información per- 
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tinente y ayudar a que el usuario recuerde mediante un 
escenario de interacción. Mandel [MAN97] define los 
principios de diseño que hacen posible que una interfaz 
reduzca la carga de memoria del usuario: 


Reducir la demanda de memoria a corto plazo. 
Cuando los usuarios se ven involucrados en tareas 
complejas, exigir una memoria a corto plazo puede ser 
significativo. La interfaz se deberá diseñar para reducir 
losrequisitos y recordar acciones y resultados anteriores. 
Esto se puede llevar a cabo mediante claves visuales 
que posibiliten al usuario reconocer acciones anteriores 
sin tenerlas que recordar. 


Establecer valorespor defecto útiles. El conjunto inicial 
de valores por defecto tendrá que ser de utilidad para al 
usuario, pero un usuario también deberá tener la capacidad 
de especificar sus propias preferencias. Sin embargo, 
deberá disponer de una opción de «reinicialización» que 
le permita volver a definir los valores por defecto. 


Definir las deficiencias que sean intuitivas. Cuando 
para diseñar un sistema se utiliza la mnemónica (por 
ejemplo, alt-P para invocar la función de imprimir), 
ésta deberá ir unida a una acción que sea fácil de 
recordar (por ejemplo, la primera letra de la tarea que 

¿Cómo se pueden diseñar 


se invoca). 
$ interfaces que reduzcan 


la carga de memoria del usuario? 


Elformato visual de la interfaz se deberá basar en una 
metáfora del mundo real. Por ejemplo, en un sistema de 
pago de facturas se deberá utilizar la metáfora de la 
chequera y el registro del cheque para conducir al usuario 
porel proceso del pago de facturas. Esto hace posible que 
el usuario comprenda bien las pistas y que no tenga que 
memorizar una secuencia secretade interacciones. 


Desglosar la información deforma progresiva. La 
interfaz deberá organizarsede formajerárquica. Esto es, 
en cualquier información sobre una tarea se deberá 
presentar un objeto o algún comportamiento en primer 
lugar a un nivel alto de abstracción. Y solo después de 
que el usuario indique su preferencia realizando la 
selección mediante el ratón se presentarán más detalles. 
Un ejemplo muy común en muchas aplicaciones de 
procesamiento de texto es la función de subrayado dado 
que es una función que pertenece al menú de estilo de 
texto. Sinembargono se muestran todas las posibilidades 
de subrayado. El usuario es el que debe seleccionar el 
subrayado, y así se presentaránentonces las opciones de 
esta función (porejemplo, subrayadosencillo, subrayado 
doble, subrayado de guiones). 


15,13, Construcción de una interfaz consistente 


La interfaz deberá adquirir y presentar la información 
de forma consecuente. Esto implica (1) que toda la 
información visual esté organizada de acuerdo con el 
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CAPÍTULO 15 DISENO DE LA INTERFAZ DE USUARIO 


slntroduzco cualquier 


diseño estándar que se mantiene en todas las presen- 
taciones de pantallas; (2) que todos los mecanismos 
de entrada se limiten a un conjunto limitado y que se 
utilicen consecuentemente por toda la aplicación, y 
que (3) los mecanismos para ir de tarea a tarea se 
hayan definido e implementado consecuentemente. 
Mandel [MAN97] define un conjunto de principios 
de diseño que ayudar a construir una interfaz conse- 
cuente: 


Permitir que el usuario realice una tarea en el 
contexto adecuado. Muchas interfaces implementan 
capas complejas de interacciones con docenas de 
imágenes de pantallas. Es importante proporcionar 
indicadores (por ejemplo, títulos de ventanas, iconos 
gráficos, codificaciones en colores consecuentes) que 
posibiliten al usuario conocer el contexto del trabajo 
que está llevando a cabo. Además, el usuario deberá 
ser capaz de determinar de dónde procede y qué 
alternativas existen para la transición a una tarea 


nueva. 


Mantener la consistencia en toda la familia de 
aplicaciones. Un conjunto de aplicaciones(o productos) 
deberá implementar las mismas reglas de diseño para 
mantener la consistencia en toda la interacción. 

Los modelos interactivos anteriores han esperanzado 
al usuario, no realicemos cambios a menos que exista 
alguna razón convincente para hacerlo. Una vez que 
una secuencia interactiva se ha convertidoen un estándar 
hecho (por ejemplo, la utilización de alt-S para grabar 
un archivo), el usuario espera utilizar esta combinación 
en todas las aplicaciones que se encuentre. Un cambio 
podría originar confusión (por ejemplo, la utilización 
de alt-S para invocar la función cambiar de tamaño). 

Los principios del diseño de interfaces tratados aquí 
y en sesiones anteriores proporcionan una guía básica 
para la ingeniería del software. En la siguiente sección 
examinaremos el proceso de diseño de la interfaz. 


¿Cómo se pueden construir 
interfaces consecuentes? 


Líneas Generales poro el diseño 
de lo interíoces. 
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INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRÁCTICO 


El proceso global para el diseño de la interfaz de usua- 
rio comienza con la creación de diferentes modelos de 
funcionamiento del sistema (la percepción desde fue- 
ra). Es entonces cuando se determinan las tareas orien- 
tadas al hombre y a la¡máquina que se requieren para 
lograr el funcionamiento del sistema; se tienen en con- 
sideración los temas de diseño que se aplican a todos 
los diseños de interfaces; se utilizan herramientas para 
generar prototipos y por último para implementar el 
modelo de diseño, y evaluar la calidad del resultado. 


15.2.1. Modelos de diseño de la interfaz 


Cuando se va a diseñar la interfaz de usuario entran en 
juego cuatro modelos diferentes. El ingeniero del soft- 
ware crea un modelo de diseño; cualquier otro ingenie- 
ro (o el mismo ingeniero del software) establece un 
modelo de usuario, el usuario final desarrolla una ima- 
gen mental que se suele llamar modelo de usuario oper- 
cepción del usuario, y los que implementan el sistema 
crean una imagen de sistema [RUBSS]. Desgraciada- 
mente, todos y cada uno de los modelos pueden diferir 
significativamente. El papel del diseñador de interfaz 
es reconciliar estas diferencias y derivar una represen- 
tación consecuente de la interfaz. 


Referencia 


Una fuente excelente de directrices de diseño y referencias 
se puede encontrar en www.ibm.com /ibm/easy/ 


Un modelo de diseño de un sistema completo incor- 
pora las representaciones del software en función de los 
datos, arquitectura, interfaz y procedimiento. La espe- 
cificación de los requisitos puede que establezca cier- 
tas limitaciones que ayudarán a definir al usuario del 
sistema, pero el diseño de la interfaz suele ser un único 
tema secundario de modelo de interfaz. 

El modelo de usuario representa el perfil de los usua- 
rios finales del sistema. Para construir una interfaz de 
usuario efectiva, «todo diseño deberá comenzar por 
conocer los usuarios destino, así como los perfiles de 
edad, sexo, habilidades físicas, educación, anteceden- 
tes culturales O étnicos, motivación, objetivos y perso- 
nalidad» [SCH87] Además de esto se pueden establecer 
las siguientes categorías de usuarios: 

+ principiantes: en general no tienen conocimientos 
sintáctico? ni conocimientos semánticos? de la uti- 
lización de la aplicación o del sistema; 


* Por supuesto esto no es como debena ser. Para sistemas interactivos, 
el diseño de la interfaz es tan importante como el diseño de los datos, 
arquitectura O el de componentes. 

2 En este contexto el conocimiento sintáctico se refiere a la mecánica 
de interacción que se requiere para utilizar la interfaz de forma eficaz. 
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+ Uusuariosesporádicosy con conocimientos:poseen 
un conocimiento semántico razonable, pero una 
retención baja de la información necesaria para utl- 
lizar la interfaz; 


usuarios frecuentes y con conocimientos: poseen 

el conocimiento sintáctico y semántico suficiente 
como para llegar al «síndromedel usuario avanzado), 
esto es, individuos que buscan interrupciones breves 

y modos abreviados de interacción. 


utilizan los profesionales 
quieren decir «idiota» 


La percepción del sistema (el modelo de usuario) es 
la imagen del sistema que el usuario final tiene en su 
mente. Por ejemplo, si se preguntara a un usuario de un 
procesador de texto en particular que describiera su for- 
ma de manejar el programa, la respuesta vendría guia- 
da por la percepción del sistema. La precisión de la 
descripción dependerá del perfil del usuario (por ejem- 
plo, los principiantes harían lo posible por responder 
con una respuesta muy elemental) y de la familiaridad 
global con el software del dominio de la aplicación. Un 
usuario que comprenda por completo los procesadores 
de texto, aunque puede que haya trabajado solo una vez 
con ese procesador específico, es posible que propor- 
cione de verdad una descripción más completa de su 
funcionamiento que el principiante que haya pasado 
unas cuantas semanas intentando aprender el funciona- 
miento del sistema. 


La imagen del sistema es una combinación de facha- 
da externa del sistema basado en computadora (la apa- 
riencia del sistema) y la información de soporte (libros, 
manuales, cintas de vídeo, archivos de ayuda) todo lo 
cual ayuda a describir la sintaxis y la semántica del sis- 
tema. Cuando la imagen y la percepción del sistema 
coinciden, los usuarios generalmente se sienten a gus- 
to con el software y con su funcionamiento. Para llevar 
a cabo esta «mezcla» de modelos, el modelo de diseño 
deberá desarrollarse con el fin de acoplar la informa- 
ción del modelo de usuario, y la imagen del sistema 
deberá reflejar de forma precisa la información sintác- 
tica y semántica de la interfaz. 


Los modelos descritos anteriormente en esta sección 
son «abstracciones de lo que el usuario está haciendo o 
piensa que está haciendo o de lo que cualquier otra per- 


3 El conocimiento semántico se refiere al sentido subsiguientede apli- 
cación —una comprensión de la realización de todas las funciones, 
del significado de entrada y salida, de las metas y objetivos del sis- 
tema—. 
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sona piensa que debería estar haciendo cuando utiliza 
un sistema interactivo» [MON84]. Esencialmente, estos 
modelos permiten que el diseñador de la interfaz satis- 
faga un elemento clave del principio más importante 
del diseño de la interfaz de usuario: «quien conoce al 
usuario, conoce las tareas». 


da 
CLAVE 


Cuando la imagen del sistema y la petcepciondel sistema 
coinciden, el usuario puede utilizar la aplicacion de forma 
efectivo. 


1522. El proceso de diseño de la interfaz 
de usuario 

El proceso de diseño de las interfaces de usuario es ite- 
rativo y se puede representar mediante un modelo espi- 
ral similar al abordado en el Capítulo 2. En la Figura 
15.1 se puede observar que el proceso de diseño de la 
interfaz de usuario acompaña cuatro actividades distin- 
tas de marco de trabajo [MAN97]: 


1. Análisis y modelado de usuarios, tareas y entornos. 
2. Diseño de la interfaz 

3. Implementación de la interfaz 

4. Validación de la interfaz 


Validación 


, Análisis de usuarios, 
de la interfaz 


tareas y entornos 


implementación Diseño de la interfaz 


FIGURA 15.1. El proceso de diseño de la interfaz de usuario. 


La espiral que se muestra en la Figura 15.1 implica 
que cada una de las tareas anteriores aparecerán más de 
una vez, en donde a medida que se avanza por la espi- 
ral se representará la elaboración adicional de los requi- 
sitos yel diseño resultante. En la mayoría de los casos, 
la actividad de implementación implica la generación 
de prototipos —la única forma práctica para validar lo 
que se ha diseñado —. 

La actividad de análisis inicial se concentraen el per- 
fil de los usuarios que van a interactuar con el sistema. 
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CAPITULO i> DISEÑO DE LA INTERFAZ DE USUARIO 


Se registran el nivel de conocimiento, la comprensión 
del negocio y la receptividad general del nuevo siste- 
ma, y se definen diferentes categorías de usuarios. En 
cada categoría se lleva a cabo la elicitación de los requi- 
sitos. Esencialmente, el ingeniero del software intenta 
comprender la percepción del sistema (Sección 15.2.1) 
para cada clase de usuario. 


Una vez definidos los requisitos generales, se lleva a 
cabo un análisis más detallado de las tareas. Se identif1- 
can, describen y elaboran las tareas que lleva a cabo el 
usuario para conseguirlos objetivos (por encima de la can- 
tidad de pasos iterativos a través de la espiral). El análi- 
sis de tareas se estudia detalladamenteen la Sección 15.3. 

El análisis del entorno de usuario se centra en el 
entorno del trabajo físico. Entre las preguntas que se 
formulan se encuentran las siguientes: 

¿Dónde se ubicará físicamente la interfaz? 

¿Dónde se situará el usuario? ¿Llevará a cabo tareas 
no relacionadas con el interfaz? 

¿Se adapta bien el hardware a las limitaciones de luz, 
espacio o ruido? 


Esta recopilación de información que forma parte de 
la actividad de análisis se utiliza para crear un modelo 
de análisis para la interfaz. Mediante esta base de mode- 
lo se comienza la actividad de diseño. 


¿Cuál es el objetivo 
del diseño de lo interíoz 
de usuario? 


El objetivo del diseño de la interfazes definir un con- 
junto de objetos y acciones de interfaz (y sus represen- 
taciones en la pantalla) que posibiliten al usuario llevar 
a cabo todas las tareas definidas de forma que cumplan 
todos los objetivos de usabilidad definidos por el siste- 
ma. El diseño de la interfaz se aborda más detallada- 
mente en la Sección 15.4 

La actividad de implementación comienza normal- 
mente con la creación de un prototipo que permita eva- 
luar los escenarios de utilización. A medida que avanza 
el proceso de diseño iterativo, y para completar la cons- 
trucción de la interfaz, se puede utilizar un kit de herra- 
mientas de usuario (Sección 15.5). 

La validación se centraen: (1) la habilidad de la inter- 
faz para implementar correctamente todas la tareas del 
usuario, para acoplar todas las variaciones de tareas, y 
para archivar todos los requisitos generales del usuario; 
(2) el grado de facilidad de utilización de la interfaz y 
de aprendizaje, y (3) la aceptación de la interfaz por par- 
te del usuario como una herramienta Útil en su trabajo. 
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INGENIERÍA DEL SOFTWARE. UN ENFUQUE PRACTICO 


En el Capítulo 13 se estudió la elaboración paso a paso 
(llamada también refinamiento paso a paso y descompo- 
sición funcional) como mecanismo para refinar las tareas 
de procesamiento necesarias para que el software lleve a 
cabo la función deseada. Más adelanteen este mismo libro 
tendremos en consideración el análisis orientado a obje- 
tos como enfoque de modelado para los sistemas basados 
en computadora. El análisis de tareas para el diseño de la 
interfaz O bien utiliza un enfoqueelaborativoo bien orien- 
tado a objetos, pero aplicando este enfoque a las activi- 
dades humanas. 

El análisis de tareas se puede aplicar de dos maneras. 
Como ya hemos destacado anteriormente, un sistema 
interactivo basado en computadora se suele utilizar para 
reemplazar una actividad manual Oo semi-manual. Para 
comprender las tareas que se han de llevar a cabo para 
lograr el objetivo de la actividad, un ingeniero” deberá 
entenderlas tareas que realizan los hombres actualmente 
(cuando se utiliza un enfoque manual) y hacer corres- 
ponder esta tareas con un conjunto de tareas similar (aun- 
que no necesariamente idénticas) que se implementan en 
el contexto de la interfaz de usuario. Da forma alternati- 
va, el ingenieropuede estudiar la especificación existen- 
te para la solución basada en computadora y extraer un 
conjuntode tareas que se ajusten al modelo de usuario, al 
modelo de diseño y a la percepción del sistema. 

Independientemente del enfoque global utilizado para 
el análisis de tareas, el ingeniero deberá en primer lugar 
definirlas y clasificarlas. Ya se ha descrito anteriormente 
que el enfoque es una elaboración paso a paso. Porejem- 
plo, supongamos que una compañía pequeña quiere cons- 
truir un sistema de diseño asistido por computadora 
explícitamente para diseñadores de interiores. Al obser- 
var aun diseñador de interiores en su trabajo, el ingenie- 
ro se da cuenta y notifica que el diseño interior se compone 


de una serie de actividades importantes: diseño del mobi- 
liario, selección de tejidos y materiales, selección de deco- 
rados en paredes y ventanas, presentación (al cliente), 
costes y compras. Todas y cada una de estas tareas pue- 
den elaborarseen otras subtareas. Por ejemplo, el diseño 
del mobiliario puede refinarse en las tareas siguientes: (1) 
dibujar el plano de la casa con las dimensionesde las habi- 
taciones; (2) ubicar ventanas y puertas en los lugares ade- 
cuados; (3) utilizar plantillas de muebles para dibujar en 
el plano un esbozo del mobiliario a escala; (3) mover el 
esbozo del mobiliario para mejorar su colocación; ( 5 Jeti- 
quetarel esbozo del mobiliario; (6) dibujar las dimensio- 
nes para mostrar la colocación; (7) realizar un dibujo en 
perspectiva para el cliente. Para las otras tareas impor- 
tantes del enfoque se puede utilizar un método similar. 


5 
a 


CLAVE 


las tareas humanas se definen y se clasifican como parte 
del anólisis de las tareas. Para refinarlos tareas se utiliza 
un proceso de elaboración. De forma alternativa, 

se identifican y se refinan los objetos y las acciones. 


Las subtareas (1)-(7) pueden recibir más refinamien- 
to. Las subtareas (1)-(6) se llevarán a cabo mediante la 
manipulación de información y mediante la realización 
de acciones dentro de la interfaz de usuario. Por otro lado, 
la subtarea (7) se podrá llevar a cabo automáticamenteen 
el software y dará como resultado muy poca interacción 
directa con el usuario. El modelo de diseño de la interfaz 
deberá adaptarsea cada una de estas tareas de forma con- 
secuente con el modelo del usuario (el perfil de un dise- 
ñador «típico» de interiores) y con la percepción del 
sistema (lo que el diseñador de interiores espera de un sis- 
tema automatizado). 


Una vez finalizado el análisis de tareas, quedan defini- 
das detalladamente todas (u objetos y acciones) las que 
requiere el usuario final y comienza la actividad del dise- 
ño de la interfaz. Mediante el enfoque que se muestra a 
continuación se podrán llevar a cabo los primeros pasos 
del diseño de la interfaz [NOR86]: 


1. Establecerlos objetivo? e intencionespara cadatarea. 


ls ¿Cuáles son los pasos 
que hay que seguir para Hevor 
a cubo el diseño de la interfaz? 


% En muchos casos las actividades descritas en esta sección son lle- 
vadas a cabo por un ingeniero del software. Esperemos que el indi- 
viduo tenga experiencia en ingeniería humana y en el diseño de la 
interfaz de usuario. 


2. Hacer corresponder cada objetivo/intención con una 
secuencia de acciones específicas 


3, Especificar la secuencia de acciones de tareas y sub- 
tareas, también llamado escenario del usuario, de la 
manera en que se ejecutarán a nivel de la interfaz. 


4. Indicar el estado del sistema, esto es, el aspecto que 
tiene la interfaz cuando se está llevando a cabo el 
escenario del usuario. 


5. Definir los mecanismo de control, esto es, los obje- 
tos y acciones disponibles para que el usuario altere 
el estado del sistema. 


5 Entre los objetivos se pueden incluirla consideración de la utilidad de 
las tareas, la efectividad al llevar a cabo el objetivo comercial primor- 
dial, el grado de rapidez de aprendizaje de las tareas y el grado de satis- 
facción de los usuarios con la implementación final de la tarea. 
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6. Mostrar la forma en que los mecanismos de control 
afectan al estado del sistema. 


7. Indicar la forma en que el usuario interpreta el estado 
del sistema a partir de la información proporcionada 
gracias a la interfaz. 


Aunque el diseñador de la interfaz se guía por las 
reglas de oro abordadas en la Sección 15.1,deberá con- 
siderar la forma en que se va a implementar la interfaz, 
el entorno (por ejemplo, tecnología de pantalla, sistema 
operativo, herramientas de desarrollo) que se va a uti- 
lizar y otros elementos de la aplicación que «se encuen- 
tren por detrás» de la interfaz. 


15,41, Definición de objetos y acciones 
de la interfaz 


Un paso importante en el diseño de la interfaz es la defi- 
nición de los objetos y acciones que se van a aplicar. 
Para llevar a cabo esta definición, el escenario del usua- 
rio se analiza sintácticamente de manera muy similar a 
como se analizaban las narrativas de procesamiento del 
Capítulo 12. Esto es, se escribe la descripción del esce- 
nario de un usuario. Los sustantivos (objetos) y los ver- 
bos (acciones) se aíslan para crear una lista de objetos 
y de acciones. 


Referencia cruzada 


En la Sección 12.6.2 se puede encontrar un estudio 
completa del análisissérántico gramatical. 


Una vez que se han definido y elaborado iterativa- 
mente tanto los objetos como las acciones, se estable- 
cen categorías por tipos. Los objetos se identifican como 
objetos origen, destino y de aplicación. Un objeto ori- 
gen (por ejemplo, un icono de informes) se arrastra y se 
coloca sobre otro objeto destino (por ejemplo, un icono 
de impresora). La implicación de esta acción es crear 
una copia impresa de un informe. Un objeto de aplica- 
ción representa los datos específicos de la aplicación 
que no se manipulan directamentecomo parte de la inte- 
racción de la pantalla. Por ejemplo, una lista de correo 
postal se utiliza para almacenar los nombres que se uti- 
lizarán para un correo postal. Esta lista se puede orde- 
nar, fusionar o purgar (acciones basadas en menú) pero 
no se puede arrastrar y colocar mediante la interacción 
del usuario. 


$ ¿Qué es el formato 
de pantalla y cómo se aplica? 


Una vez que el diseñador queda satisfechocon la defi- 
nición de todos los objetos y acciones importantes (para 
una iteración de diseño), se lleva a cabo elformato de 


CAPLIULU 19 LIBLÑO DE LA INTERFAZ DE USUARIO 


pantalla. Al igual que otras actividades de diseño de la 
interfaz, el formato de pantalla es un proceso interactivo 
en donde se lleva a cabo el diseño gráfico y la colocación 
de los iconos, la definición del texto descriptivo en pan- 
talla, la especificación y títulos para las ventanas, y la 
definición de los elementos del menú principales y secun- 
darios. Si una metáfora con el mundo real es adecuada 
para la aplicación, queda especificada en ese momento y 
el formato se organizapara complementaresa metáfora. 

Para mostrar la breve ilustraciónde los pasos de dise- 
ño descritos anteriormente, tomemos en consideración 
un escenario de usuario para la versión avanzada del 
sistema HogarSeguro (descrito en capítulos anteriores). 
En la versión avanzada, se puede acceder a HogarSe- 
guro mediante módem o Intemet. Una aplicación para 
PC permite que un propietario compruebe el estado de 
la casa desde una localización remota, reinicializar la 
configuración HogarSeguro, activar y desactivar el sis- 
tema, (empleando una opción de vídeo con un coste 
extra), y supervisar visualmente las habitaciones den- 
tro de la casa. A continuación, se muestra un escenario 
preliminar de usuario para la interfaz: 


Referencia cruzada 


El escenario descrito aquí es similar los cosos 
de estudio descritos en el Copítulo-17, 


Escenario.El propietario de la casa desea acceder al sis- 
tema HogarSeguro instalado en su casa. Mediante el siste- 
ma operativo de un PC remoto (por ejemplo, un portátil que 
el propietario se lleve al trabajo o de viaje), el propietario 
determina el estado del sistema de alarma, arma o desarma 
el sistema, reconfigura las zonas de seguridad y observa las 
diferentes habitaciones de la casa mediante la preinstalación 
de una cámara de vídeo. 


Para acceder a HogarSeguro desde una localización remo- 
ta, el propietario proporciona un identificador y una contrase- 
ña. Con esto se definen los niveles de acceso (por ejemplo, 
todos los usuarios puede que no tengan la capacidad de recon- 
figurar el sistema) y se proporciona seguridad. Una vez vali- 
dados, el usuario (con los privilegios para el acceso) comprueba 
el estado del sistema, y cambiael estado armando y desarmando 
HogarSeguro. El usuario reconfigura el sistema visualizando 
todas las zonas configuradas actualmente, modificandolas zonas 
cuando se requiera. El usuario observa el interior de la casa 
mediante cámaras de vídeo estratégicamenteubicadas. El usua- 
rio puede utilizar las cámaras para recorrer todo el interior y 
ampliarlopara ofrecer diferentes visiones del interior de la casa. 


Tareas del propietario: 
* acceder al sistema HogarSeguro; 


* introducir un 1D y una contraseña para permitir un acceso 
remoto; 


= comprobar el estado del sistema; 


« activaro desactivarel sistema HogarSeguro; 


$ la opción de vídeo posibilita al usuario colocar una cámara 
de vídeo en lugares clave por la casa y examinar la salida desde una 
localización remota. ¿El Gran Hermano? 
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* visualizarel plano de la casay las localizaciones de los sen- 
sores; 

= visualizarzonas en el plano de la casa; 

» cambiar zonas en el plano de la casa; 

* visualizar las localizaciones de las cámaras de vídeo en el 
plano de la casa; 

* seleccionarla cámara de vídeo para tener visión; 

» observar las imágenes de vídeo (cuatro encuadres por 
segundo); 

* recorrery ampliarlas habitacionescon la cámara de vídeo. 


Los objetos (negrita) y las acciones (cursiva) se 
extraen de la lista de tareas del propietario descritas 
anteriormente. La mayoría de los objetos anteriores son 
objetos de aplicaciones. Sin embargo la localización de 
la cámara de vídeo (un objeto origen) se arrastra y se 
coloca sobre la cámara de vídeo (un objeto destino) para 
crear una imagen de vídeo (una ventana con la presen- 
tación de un vídeo). 

Para la supervisión del vídeo se crea un esbozo del 
formato de pantalla (Fig. 15.2).Para invocar la imagen 
de vídeo, se selecciona un icono de localización de 
cámara de vídeo C, ubicado en el plano de la casa que 
se visualiza en la ventana de supervisión.En este caso, 
la localización de una cámara en la sala de estar (SB), 
se arrastra y se coloca sobre el icono de vídeo de cáma- 
ra en la parte superior izquierda de la pantalla. Enton- 
ces, mediante la visualización del recorrido realizado 
por el vídeo desde la cámara localizada en la sala de 
estar (SE), aparece la ventana de imagen de vídeo. Las 
diapositivas de control del recorrido por las habitacio- 
nes y de las ampliaciones se utilizan para controlar la 
amplitud y la dirección de la imagen de vídeo. Para 
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FIGURA 15.2. Formato preliminar de pantalla. 
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seleccionar una visión desde otra cámara, el usuario 
simplemente arrastra y coloca el icono de localización 
de cámara dentro del icono cámara del ángulo supe- 
rior izquierdo de la pantalla. 

Esta muestra de esbozo de formato tendría que ir 
complementado mediante una ampliación de todos los 
elementos del menú dentro de la barra de menú, indi- 
cando las acciones disponibles para el (estado) modo de 
supervisión del video. Durante el diseño de la interfaz 
se debería crear un conjunto completo de esbozos para 
todas y cada una de las tareas del propietario descritas 
en el escenario del usuario. 


15.4.2. Problemas del diseño 


A medida que la interfaz de usuario va evolucionando 
casi siempre afloran cuatro temas comunes de diseño: 
el tiempo de respuesta del sistema, los servicios de ayu- 
da al usuario, la manipulación de información de erro- 
res y el etiquetado de órdenes. Desgraciadamente, 
muchos diseñadores no abordan estos temas dentro del 
proceso de diseño hasta que es relativamente tarde (algu- 
nas veces no se siente la aparición de un error hasta que 
se dispone del prototipo operativo). El resultado suele 
ser una iteración innecesaria, demoras de proyecto y 
frustración del usuario. Es infinitamente mejor estable- 
cer el tema de diseño que se vaya a tener en cuenta al 
iniciar el diseño del software, es decir cuando los cam- 
bios son fáciles y los costes más reducidos. 

Para muchas aplicaciones interactivas el tiempo de 
respuesta del sistema es el principal motivo de queja. 
En general, el tiempo de respuesta del sistema se mide 
desde el punto de vista que el usuario realiza la acción 
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de control (por ejemplo, pulsar la tecla intro o pulsar el 
botón del ratón) hasta que el software responde con la 
salida o acción deseada. 

El tiempo de respuesta del sistema tiene dos carac- 
terísticas importantes: la duración y la variabilidad. Si 
la duración de la respuesta del sistema es demasiado 
larga, es inevitable obtener como resultado la frustra- 
ción y el estrés del usuario. Sin embargo, si la interfaz 
va marcando el ritmo del usuario una duración breve 
del tiempo de respuesta puede ser también perjudicial. 
Un tiempo de respuesta rápido puede obligar a que el 
usuario se precipite y cometa errores. 


Consuof) 


Sino sepuede evitar uno respuesto variable, asegúrese 
de proporcionar alguna indicación visual del progreso 
pora que elusuario sepa lo que está ocurriendo. 


La variabilidad se refiere a la desviación del tiempo 
derespuestapromedio, y en muchos aspectos es la carac- 
terística más importante del tiempo de respuesta. Una 
variabilidad baja posibilita al usuario establecer un rit- 
mo de interacción, aunque el tiempo de respuesta sea 
relativamente largo. Por ejemplo, es preferible obtener 
una segunda respuesta de una orden a una respuesta que 
varíe de 0,1 a 2,5 segundos. El usuario siempre estará 
desconcertado y preguntándose si ha ocurrido algo «dife- 
rente» detrás de la escena. 

Casi todos los usuarios de un sistema interactivo basa- 
do en computadorarequieren ayuda, ahora y siempre. Los 
dos tipos de funciones de ayuda más comunes son: inte- 
gradas y complementarias(añadibles).[RUB88]. Se dise- 
ña una función de ayuda integrada dentro del mismo 
software desde el principio. Suele ser sensible al contex- 
to, lo que posibilita al usuario seleccionar entre los temas 
que sean relevantes para las acciones que esté llevando a 
cabo en ese momento. Obviamenteesto reduce el tiempo 
que requiere para obtener ayuda, e incrementa su «fami- 
liaridad» con la interfaz. Una función de ayuda comple- 
mentaria se añade al software una vez construido el 
sistema. En muchos aspectos es muy similar a un manual 
de usuario en línea con una capacidad limitada de con- 
sulta. Es posible que el usuario tenga que buscar en una 
lista de miles de temas para encontrar la guía adecuada, 
entrando normalmente en las ayudas incorrectas y reci- 
biendo mucha información irrelevante. No hay ninguna 
duda de que es preferible el enfoquede funciones de ayu- 
da integradas al enfoque de funciones complementarias. 


) ¿Cuales son los temas de diseño 
que deberán tenerse en cuenta 
en la construcción de las funciones 
de ayuda? 


Cuando se va a considerar un servicio de ayuda hay 
una serie de temas de diseño que deberán abordarse 
[RUBSS]: 
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+ ¿Se necesitará disponer de todas las funciones del 
sistema en cualquier momento durante la interacción 
del sistema? Opciones: ayuda solo para un subcon- 
junto de todas las funciones y acciones; ayuda para 
todas las funciones. 


+ ¿De qué forma solicitará ayuda el usuario? Opcio- 
nes: un menú de ayuda; una tecla de función espe- 
cial; una orden de AYUDA. 


» ¿Cómo serepresentará la ayuda? Opciones: una ven- 
tana separada; una referencia a un documento impreso 
(no es lo ideal); una sugerencia de una o dos líneas 
que surge en una localización fija en la pantalla. 


+ ¿Cómo regresará el usuario a la interacción normal? 
Opciones: un botón de retorno visualizado en la pan- 
talla; una tecla de función o una secuenciade control. 


+ ¿Cómo se estructurarála información sobre la panta- 
lla? Opciones: una estructura «plana» donde el acceso 
a la información se realiza mediante una contraseña; 
una jerarquía estratificada de información que va pro- 
porcionando más datos a medida que el usuario va 
entrando por la estructura; la utilización de hipertexto. 


Cuando ha salido algo mal, los mensajes de error y 
las sugerencias son «malas noticias» para los usuarios 
de sistemas interactivos. En el peor de los casos, estos 
mensajes imparten información sin utilizar o engañosa 
y sirven solo para incrementar la frustración del usua- 
rio. Existen muy pocos usuarios que puedan decir que 
no se han encontrado con un error del tipo: 


FALLO GRAVE DEL SISTEMA - -  14A 


En algún lugar debe existir una explicación del error 
14A, o sino ¿por qué habrá incluido el diseñador esta 
identificación? A pesar de esto, el mensaje de error no 
proporciona una indicación verdadera de lo que va mal 
O de donde mirar para obtener más información. Un 
mensaje de error como el que se ha presentado ante- 
riormente no hace nada por aliviar la ansiedad del usua- 
rio O por ayudar a solucionar el problema. 

En general, todos los mensajes de error O sugeren- 
cias de un sistema interactivo deberán tener las carac- 
terísticas siguientes: 


+ El mensaje deberá describir el problema en unajerga 
que el usuario pueda entender. 


» El mensaje deberá proporcionar consejos construc- 
tivos para recuperarse de un error. 


- El mensaje deberá indicar cualquier consecuencia 
negativa del error (por ejemplo, los archivos de datos 
posiblemente deteriorados) para que el usuario pueda 
comprobar y garantizar que no hay ninguno (y corre- 
girlos si existen). 


Cons) 


Dupliqueelesfuerzo y los palabras al solucionarerrores 
cuandopiense que necesito uno función de ayuda y, 
de estoforma, es probable que consigo un buen resultado. 
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El mensaje deberá ir seguido por una clave audible 
o visual. Esto es, para acompañar la visualización 
del mensaje se podría generar un pitido, O aparecer 
momentáneamente una luz destelleante o yisuali- 
zarse en un color que se pueda reconocer fácilmente 
como el «color del error». 


El mensaje no deberá tener «sentencias». Esto es, las 
palabras del mensaje nunca deberán culparal usuario. 


Dado que a nadie le gusta realmente tener malas noti- 
cias, a muy pocos usuarios les gustará tener un mensaje 
de error independientemente del diseño. No obstante, 
una filosofía eficaz de mensajes de error puede ayudar 
mucho a la hora de mejorar la calidad de un sistema 
interactivo y reducirá significativamente la frustración 
del usuario cuando aparecen problemas. 

Anteriormente las órdenes escritas o tecleadas eran 
el modo de interacción más común entre el usuario y el 


software del sistema, y se utilizaban normalmente para 
aplicaciones de todo tipo. Actualmente, la utilización 
de interfaces orientadas a ventanas en donde solo se 
señala y se selecciona, ha reducido el hecho de depen- 
der de órdenes tecleadas, aunque muchos usuarios avan- 
zados siguen prefiriendo el modo de interacción 
orientado a órdenes. Cuando se proporcionan Órdenes 
escritas como modo de interacción surge una serie de 
temas de diseño: 

¿Se corresponden todas las opciones del menú con 
su órdenes? 

¿Qué formas adquirirán las órdenes? Opciones: una 
secuencia de control (por ejemplo, alt-P); teclas de 
función; una palabra tecleada. 

¿Será difícil aprender y recordar las órdenes? ¿Qué 
se puede hacer si se olvida una orden? 

¿Podrá personalizar o abreviarel usuario las órdenes? 


Una vez creado el modelo de diseño, se implementa 
como un prototipo”, que los usuarios han examinado 
(aquellos que adaptan el modelo del usuario descrito 
anteriormente), y que se ha basado en los comentarios 
de los usuarios. 

Para acoplar este enfoque de diseño iterativo se ha 
desarrollado una clase extensa de herramientas diseño 
de interfaz y de generación de prototipos. Estas herra- 
mientas así llamadas,juego de herramientas de la inter- 

faz de usuario o sistemas de desarrollo de la interfaz de 
usuario (SDIU), proporcionan componentes u objetos 
que facilitan la creación de ventanas, menús, interacción 
de dispositivos, mensajes de error, Órdenes y muchos 
otros elementos de un entorno interactivo. 

Mediante los componentes de software preestable- 
cidos que se pueden utilizar para crear una interfaz de 
usuario, un SDIU proporcionará los mecanismos 
[MYES9] para: 

gestionar los dispositivos de salida (tales como el 
ratón o el teclado); 


validar la entrada del usuario; 


manipular los errores y visualizar mensajes de error; 


proporcionar una respuesta (por ejemplo, un eco auto- 
mático de la entrada) 


proporcionar ayuda e indicaciones de solicitud de 
entrada de órdenes; 


manipular ventanas y campos, desplazarse por las 
ventanas; 

establecer conexiones entre el software de la aplica- 
ción y la interfaz; 

aislar la aplicación de las funciones de gestión de la 
interfaz; 


permitir que el usuario personalice la interfaz. 


Diseño de la Interfaz de usuario 


Estas funciones se pueden implementar mediante un 
enfoque gráfico o basado en lenguajes. 


Una vez que se ha creado un prototipo de interfaz de usua- 
río, deberá sufrir una evaluación para determinar si cum- 
ple las necesidades del usuario. La evaluación podrá 
abarcarun espectro de formalidad:desde «pruebas» infor- 
males en donde el usuario proporciona respuestas espon- 


7 Debe destacarse que en algunos casos (porejemplo, los indicadores 
del panel de los aviones),el primer paso debena ser simular la inter- 
faz en un dispositivo en vez de utilizar el hardware del indicador. 
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táneas hasta un estudio formalmente diseñado que utili- 
zará métodos estadísticos para la evaluación de cuestio- 
narios cumplimentadospor un grupo de usuarios finales. 

El ciclo de evaluación de la interfaz adquiere forma 
en la Figura 15.3. Una vez finalizado el modelo de dise- 
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ño, se crea un prototipo de primer nivel. Este prototipo 
es evaluado por el usuario, que es quien proporcionará 
al diseñador los comentarios directos sobre la eficacia 
de la interfaz. Además, si se utilizan técnicas formales 
de evaluación (por ejemplo, cuestionarios,hojas de eva- 
luación), es posible que el diseñador extraiga informa- 
ción de estos datos (por ejemplo, el 80 por 100de los 
usuarios no mostró afinidad con el mecanismo para gra- 
bar archivos de datos). Las modificaciones que se rea- 
licen sobre el diseño se basarán en la entrada del usuario 
y entonces se creará el prototipo de segundo nivel. El 
ciclo de evaluación continúa hasta que ya no sean nece- 
sarias más modificaciones del diseño de la interfaz. 


E vieja 
escribir delante que pueda 
a donde la mente 
con el universo y los 


El enfoque de generación de prototipos es eficaz, 
ahora bien ¿es posible evaluar la calidad de la interfaz 
de usuario antes de construir un prototipo? Si los pro- 
blemas se pueden descubrir y solucionar rápidamente, 
el número de bucles en el ciclo de evaluación se redu- 
cirá y el tiempo de desarrollo se acortará. Si se ha crea- 
do un modelo de diseño de la interfaz, durante las 
primeras revisiones del diseño se podrán aplicar una 
serie de criterios [MOR81] de evaluación: 


Diseño 
preliminar 


Construcción 
de la interfaz 
prototipo n.* 1 


Construcción 
de la interfaz 
prototipo n.* n 


Realización El usuario 
de las evalúa 
modificaciones la interfaz 
del diseño 


La evaluación 
es estudiada 
por el diseñador 


El diseño 
de la interfaz 
está finalizada 


FIGURA 15.3. El ciclo de evaluación de diseño de la interfaz. 
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. La duración y la complejidad de la especificación 
que se haya escrito del sistema y de su interfaz pro- 
porcionan una indicación de la cantidad de aprendi- 
zaje que requieren los usuarios del sistema. 


. La cantidad de tareasespecificadasy la cantidad media 
de acciones por tarea proporcionan una indicación del 
tiempo y de la eficacia global del sistema. 


. La cantidad de acciones, tareas y estados de sistemas 
indicados con el modelo de diseño indican la carga de 
memoria que tienen los usuarios del sistema. 


. El estilo de la interfaz, las funciones de ayuda y el 
protocolo de solución de errores proporcionan una 
indicación general de la complejidad de la interfaz 
y el grado de aceptación por parte del usuario. 


Una vez construido el primer prototipo, el diseñador 
puede recopilar una diversidad de datos cualitativos y 
cualificativos que ayudarán a evaluar la interfaz. Para 
recopilar los datos cualitativos, se pueden distribuircues- 
tionarios a los usuarios del prototipo. Las preguntas pue- 
den ser (1) del tipo de respuesta si/no; (2) respuesta 
numérica; (3) respuesta con escala de valoración (sub- 
jetiva), o (4) respuesta por porcentajes (subjetiva). A 
continuación se muestran unos ejemplos: 

1. ¿Eran claros los iconos? En caso negativo, ¿Qué 
iconos no eran claros? 


. ¿Eran fáciles de recordar y de invocar las acciones? 


uy 


. ¿Cuántas acciones diferentes ha utilizado? 


4. ¿Resultaron fáciles de aprenderlas operacionesbási- 
cas del sistema? (valoración de la 5) 


5. En comparación con otras interfaces que haya utili- 


zado, ¿Cómo evaluaría ésta? 


entre el 1% mejores, 10%mejores, 25% mejores, 50% 
mejores, 50% inferiores. 


E 


Interfaz de usuario. 


Si se desea obtener datos cuantitativos, se puede lle- 
var a cabo una forma de análisis para el estudio del tiempo. 
Los usuarios son observados durante la interacción; y para 
tener una guía durante la modificación de la interacción 
se recopilan y utilizan datos tales como: grupo de tareas 
finalizadas correctamente por encima del período de 
tiempo estándar; frecuencia de acciones; secuencia de 
acciones; tiempo transcurrido «mirando» la pantalla; 
número y tipo de errores, y tiempo de solución de erro- 
res; tiempo necesario para utilizar la ayuda; y cantidad de 
referencias de ayuda por período de tiempo estándar. 

Un estudio completo de los métodos de evaluación de 
la interfaz de usuario queda fueradel ámbito de este libro. 
Para más información, véase [LEA88] y [MAN97]. 
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Se puede argumentarque la interfaz de usuario es el ele- 
mento más importante de un sistema O producto basa- 
do en computadora. Si la interfaz tiene un diseño pobre, 
la capacidad que tiene el usuario de aprovecharse de la 
potencia de proceso de una aplicación se puede dificul- 
tar gravemente. En efecto, una interfaz débil puede llevar 
al fracaso de una aplicación con una implementación 
sólida y un buen diseño. 

Existen tres principios importantesque dirigen el dise- 
ño de interfaces de usuario eficaces: (1) poner el control 
en manos del usuario; (2) reducir la carga de la memoria 
del usuario; (3) construir una interfaz consecuente. Para 
lograr que una interfaz se atenga a estos principios, se 
deberá desarrollarun proceso de diseño organizado. 

El diseño de la interfaz de usuario comienza con 
la identificación de los requisitos del usuario, de las 
tareas y del entorno. El análisis de tareas es una acti- 
vidad de diseño que define las tareas y acciones del 
usuario empleando un enfoque elaborativo u orienta- 
do a objetos. 


[DUM88] Dumas, J.S., Designing User Interfacesfor Soft- 
ware, Prentice-Hall, 1988. 


[LEA88] Lea, M., «Evaluating User Interfaces Designs», User 
Interface Designfor Cornputer Systems, Halstead Press 
(Wiley), 1988. 


[MAN97] Mandel, T., The Elements of UserInterfaceDesign, 
Wiley, 1997. 


[MON84] Monk, A. (ed), Fundamentals of Human-Compu- 
ter Interaction, Academic Press, 1984. 


[MOR81] Moran, T.P., «The Command Language Grammar: 
A Representation for the User Interface of InteractiveCom- 


Una vez que se han definido las tareas, los escena- 
rios del usuario se crean y analizan para definirun con- 
junto de objetos y acciones de la interfaz. Esto es lo que 
proporciona la base para la creación del formato dela. 
pantalla, el cual representa el diseño gráfico y la colo- 
cación de iconos, la definición de un texto descriptivo 
en pantalla, la especificación y titulación de ventanas y 
la especificación de los elementos importantes y secun- 
darios del menú. Cuando se va a refinar un modelo de 
diseño para el sistema se tienen en consideracióntemas * 
de diseño tales como tiempo de respuesta, estructurade : 
Órdenes y acciones, manipulación de errores y funcio- 
nes de ayuda. Para construir un prototipo que el usua- 
rio pueda evaluar se utilizan diversas herramientas de 
implementación. 

La interfaz de usuario es la ventana del software. En 
muchos casos, la interfaz modela la percepción quetie- 
ne un usuario de la calidad del sistema. Si la ventana se 
difumina, se ondula o se quiebra, el usuario puede recha- 
zar un sistema potente basado en computadora. 


puter Systems», Intl. Journal of Man-Machine Studies, 
vol. 15, pp. 3-50. 


[MYE89] Myers, B.A., «User Interface Tools: Introduction 
and Survey», IEEE Software, Enero 1989, pp. 15-23, 


[NOR86] Norman, D.A., «Cognitive Engineering», UserCen- 
tered Systems Design, Lawrence Earlbaum Associates, 
Nueva Jersey, 1984. 


[RUB88] Rubin, T., User Interface Designfor CornputerSys- 
tems, Haldstead Press (Wiley), 1988. 


[SHN87] Shneiderman, B., Designing the User Interface, 
Addison-Wesley, 1987. 


15.1. Describala peor interfaz con la que haya trabajado algu- 
na vez y critíquela en relación con los conceptos que se han 
presentado en este capítulo. Describa la mejor interfaz con la 
que haya trabajado alguna vez y critíquela en relación con los 
conceptos presentados en este capítulo. 


15.2. Desarrolle dos principios de diseño más que «den el 
control al usuario». 


15.3. Desarrolle dos principios de diseño más que «reduzcan 
la carga de memoria del usuario», 


15.4. Desarrolle dos principios de diseño más que «ayuden 
a construir una interfaz consecuente». 


15.5. Considere una de las aplicaciones interactivas siguien- 
tes (o una aplicación asignada por su profesor): 
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a. Un sistema de autoedición 

b. un sistema de diseño asistido por computadora 

c, un sistema de diseño de interiores 

d. un sistema de matriculación automatizado para la uni- 
versidad 

e. un sistema de gestión de biblioteca 

f. un sistemade votación basada en Intemet para las elec- 
ciones públicas 

g. un sistema bancario en casa 

h, una aplicación interactiva asignada por su instructor 


Desarrolle un modelo de diseño, un modelo de usuario, una 
imagen de sistema y una percepción de sistema para cual- 
quiera de los sistemas anteriores. 
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156. Realice un análisis detallado de tareas para cualquiera 
de los sistemas que se relacionan en el Problema 15.5. Utili- 
ce un enfoque elaborativo u orientado a objetos. 


15.7. Como continuación al Problema 15.6, defina objetos y 
acciones para la aplicación que acaba de seleccionar. Identi- 
fique todos los tipos de objetos. 


15.8. Desarrolle un conjunto de formatos de pantalla con una 
definición de los elementos del menú principales y secunda- 
- rios para el sistema que haya elegido en el Problema 15.5. 


159. Desarrolle un conjunto de formatos de pantalla con una 
definición de los elementos principales y secundarios del menú 
para el sistema estándar HogarSeguro de la Sección 15.4.1. 
Puede optar por un enfoque diferente al mostrado en la Figu- 
ra 15.2 sobre un formato de pantalla. 


- 15.10.Describa el enfoque utilizado en las funciones de ayu- 
da del usuario que haya utilizado para el modelo de diseño en 


CAPITULO 15 DISEÑO DE LA INTERFAZ DE USUARIO 


el análisis de tareas que haya llevado a cabo desde el Proble- 
ma 15.6al 15.8. 


15.11. Proporcione unos cuantos ejemplos que muestren la 
razón de que la variabilidad del tiempo de respuesta pueda 
considerarse un tema a tener en cuenta. 


15.12. Desarrolle un enfoque que integre automáticamente los 
mensajes de error y una función de ayuda al usuario. Esto es, 
que el sistema reconozca automáticamente el tipo de error y 
proporcione una ventana de ayuda con sugerencias para corre- 
girlo. Realice un diseño de software razonablemente comple- 
to que tenga en consideración estructuras de datos y algoritmos. 


15.13. Desarrolle un cuestionariode evaluación de la interfaz 
que contenga20 preguntas genéricas que sepuedan aplicara la 
mayoría de las interfaces. Haga que 10 compañeros de clase 
rellenen el cuestionario del sistemade interfaz que vayan a uti- 
lizartodos. Resuma los resultados e informe de ellos a la clase. 


Aunque el libro de Donald Norman no trata específicamente 
interfaces hombre-máquina, mucho de lo que su libro (The 
Design of Everyday Things, Reissue edition, Currency/Dou- 
bleday, 1990) tiene que decir sobre la psicología de un dise- 
ño eficaz se aplicará a la interfaz de usuario. Es una lectura 
recomendada para todos los que sean serios a la hora de cons- 
tmir un diseño de interfaz de alta calidad. 

Durante la década pasada se han escrito docenas de libros 
acerca del diseño de interfaces. Sin embargo, los libros de 
Mandel [MAN97] y Shneiderman (Designing the User Inter- 

face: Strategiesfor Effective Human-Computer Interaction, 
3. ed., Addison-Wesley, 1990) continúan proporcionando el 
estudio más extenso acerca de la materia. Donnelly (In Your 
Face: The Best of Interactive Design, Rockport Publications, 
1998), Fowler, Stanwick y Smith (GUI Design Handbook, 
McGraw-Hill, 1998), Weinschenk, Jamar, y Yeo (GUI Design 
Essentials, Wiley, 1997), Galitz (The Essential Guide to User 
Interface Design: An Introduction to GUI Design Principles 
and Techniques, Wiley, 1996), Mullet y Sano (Designing 
Visual Interfuces: CommunicationOriented Techniques,Pren- 
tice Hall, 1995), y Cooper (About Face: The Essentials of 
UserInterface Design, IDG Books, 1995) han escrito estu- 
dios que proporcionan las líneas generales y principios de 
diseño adicionales así como las sugerencias para la elícita- 
ción de requisitos, modelado, implementación y comproba- 
ción del diseño. 

El análisis y modelado de tareas son las actividades fun- 
damentales del diseño de la interfaz. Hackos y Redish (User 
and Task Analysisfor Interface Design, Wiley, 1998) han 
escrito un libro especializado en estos temas y proporcionan 
un método detallado para abordar el análisis de tareas. Wood 
(UserInterface Design: Bridging the Gapfrom User Requi- 
rements to Design, CRC Press, 1997) tiene en consideración 
la actividad de análisis para interfaces y la transición hacia 
las tareas de diseño. Uno de los primeros libros que presen- 
tan el tema de los escenarios en el diseño de la interfaz de 
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usuario ha sido editado por Carroll (Scenario-Based Design: 
Envisioning Workand Technology in System Development, 
Wiley, 1995). Horrocks (Constructing the User Interface with 
Statecharts, Addison-Wesley, 1998) ha desarrollado un méto- 
do formal para el diseño de interfaces de usuario que se basa 
en el modelado del comportamiento basado en el estado. 

La actividad de evaluación se centra en la usabilidad. Los 
libros de Rubin (Handbook of Usability Testing:How to Plan, 
Design, and Conduct Effective Tests, Wiley, 1994) y Nielson 
(Usability Inspection Methods, Wiley, 1994) aborda el tema 
de forma considerable y detallada. 

La computadora Apple de Macintosh popularizó las inter- 
faces de usuario con diseños sólidos y fáciles de utilizar. El 
personal de Apple (Macintosh Human Interface Guidelines, 
Addison-Wesley, 1993)estudia la apariencia y utilización del 
ahora famoso Macintosh (y tan imitado). Uno de los prime- 
ros libros que se han escrito acerca de la interfaz de Micro- 
soft Windows fue elaborado por el personal de Microsoft(The 
Windows Guidelinesfor Software Design: An Application 
Design Guide, Microsoft Press, 1995). 

En un libro de Murphy (Front Panel: Designing Software 

for Embedded User Interfaces, R£D Books, 1998), el cual 
puede resultar de gran interés para los diseñadores del pro- 
ducto, se proporciona una guía detallada para el diseño de 
interfaces de sistemas empotrados y aborda los peligros inhe- 
rentes en controles, en manipulación de maquinaria pesada e 
interfaces para sistemas médicos y de transporte. El diseño 
de la interfaz para productos empotrados también se estudia 
en el libro de Garrett (Advanced Instrumentation and Com- 
puter 1/O Design: Real-Time System Computer Interface Engi- 
neering, IEEE, 1994). 

Una amplia variedad de fuentes de información sobre el 
diseño de la interfaz de usuario y de temas relacionados están 
disponibles en Internet. Una lista actualizada de referencias 
relevantes para la interfaz de usuario se puede encontrar en 
http://www.pressman5.com 
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CAPÍTULO 


l 6 DISEÑO A NIVEL DE COMPONENTES 


L diseño a nivel de componentes, llamado también diseño procedimental, tiene lugar des- 

pués de haber establecido los diseños de datos, de interfaces y de arquitectura. El obje- 

tivo es convertir el modelo de diseño en un software operacional. No obstante, el nivel 
de abstracción del modelo de diseño existente es relativamente alto y el nivel de abstracción del 
programa operacional es bajo. Esta conversión puede ser un desafío, abriendo las puertas a la 
introducción de errores sutiles que sean difíciles de detectar y corregir en etapas posteriores del 
proceso del software. Edsgar Dijkstra, uno de los principales valedores para la comprensión del 
diseño, escribe lo siguiente [DIJ72]: 


El software parece ser diferente de muchos otros productos, donde como norma una calidad superior 
implica un precio más elevado. Aquellos que quieran realmente un software fiable descubrirán que para 
empezar deben encontrar un medio de evitar la mayoría de los errores y, como resultado, el proceso de pro- 
gramación será menos costoso.. ..y los programadores que sean eficaces no deberán malgastar su tiempo 
depurando los programas —no deberán cometer errores desde el principio —. 


Aunque estas palabras ya se escribieron hace muchos años, hoy en día siguen siendo ver- 
dad. Cuando el modelo de diseño se convierte en código fuente, deberán' seguirse una serie de 
principios que no solo lleven a cabo la conversión, sino que «no introduzcan errores desde'el 
principio». 


VISTAZO RÁPIDO 


notaciones gráficas, tabulares y basa- 
dasentexto. 


¿Qué es? Este diseño consiste en con- ponentes representa el software que 


vertir el diseño de datos, interfaces y 
arquitecturaen un software operacio- 
nal. Para poderlo llevar a cabo, el 
diseño se deberá representar a un 
nivel de abstracción cercano a un 
código. El diseño a nivel de compo- 
nentes establece los datos algorítmi- 
cos que serequieren para manipular 
las estructuras de datos, efectuar la 
comunicación entre los componentes 
del software por medio delas interta- 
ces. e implementar los algoritmos 
asignados a cada componente 


¿Quién lo hace? Un ingeniero del soft- 


Ware. 


¿Por qué es importante? Se tiene 


quetener la capacidad de determinar 
siel programa funcionará antes de 
construirlo. El diseño a nivel de com- 


permite revisar los datos del diseño 
para sucorrección y consistencia con 
las representaciones de diseño ante- 
riores (estoes, los diseño de datos, de 
interfaces y de arquitectura). Coneste 
diseño se proporciona un medio de 
evaluar el funcionamiento de las 
estructuras de datos, interfaces y 
algoritmos. 


¿Cuáles son los pasos? Las represen- 


taciones de los diseños de datos. 
arquitectura e interfaces forman la 
basedeldiseño a nivel decomponen- 
tes. La narrativa del proceso de cada 
componente se convierte e nun mode- 
lo de diseño procedimental emplean- 
do un conjunto de construcciones de 
programación estructurada. Para 
representar estediseño seutilizan las 


¿Cuál es el producto obtenido? El 


diseño procedimental de cada compo- 
nente representado en forma de nota- 
ción gráfica, tabular obasadaentexto 
eselprimer producto de trabajo duran-* 
teel diseño a nivel de componentes. 


¿Cómo puedo estar seguro de que 


lo he hecho correctamente? 
Mediante una revisión estructurada y 
una inspección. El examen del diseño 
se realiza para determinar si las 
estructuras de los datos, las secuencias 
delproceso y las condiciones lógicas 
son correctas, y para ver siproducirán 
la transformación de datos y control 
adecuados que se asignó al compo- 
nente durante los primeros pasos del 
diseño. 


Mediante la utilización de un lenguaje de programación es posible representar el diseño a 
nivel de componentes. En esencia, el programa se crea empleando como guía el modelo de dise- 
ño. Un enfoque alternativo es representar el diseño procedimental mediante la utilización de 
alguna representación intermedia (por ejemplo, gráfica, tabular o basada en texto) que se pue- 
da transformar fácilmente en código fuente. Independientemente del mecanismo que se utilice 
para representar el diseño a nivel de componentes, la definición de las estructuras de datos, 
interfaces y algoritmos deberán ajustarse a la diversidad de líneas generales del diseño proce- 
dimental establecidas como ayuda para evitar errores durante la evolución del mismo diseño. 
En este capítulo, examinaremos estas líneas generales de diseño. 
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INGENIERÍA DEL SOFTWARE. ooo ooo 


Los fundamentos del diseño a nivel de componentes 
proceden de la década de los años sesenta, y tomaron 
cuerpo con el trabajo de Edsgar Dijkstra y sus colabo- 
radores [BOH66, DIJ65, DIJ76]. A finales de los sesen- 
ta, Dijkstra y otros propusieron la utilización de un 
conjunto de construcciones lógicas restringidas de las 
que poder formar cualquier programa. 


o en un problema nunca 
ye es. Solo pienso en cómo 
lo acabo, me doy cuento 
resultado no es bonito. 


Las construcciones son secuenciales, condicionales 
y repetitivas. La construcción secuencial implementa 
los pasos del proceso esenciales para la especificación 
de cualquier algoritmo. La condicional proporciona las 
funciones para procesos seleccionados a partir de una 
condición lógica y la repetitiva proporciona los bucles. 
Las tres construcciones son fundamentales para lapro- 
gramación estructurada —una técnica importante de 
diseño a nivel de componentes —. 

Las construcciones estructuradasse propusieron para 
restringir el diseño procedimental del software a un 
número reducido de operaciones predecibles. La métri- 
ca de la complejidad (Capítulo 19) indica que la utili- 
zación de construcciones estructuradas reduce la 
complejidad del programa y, por tanto, mejora la capa- 
cidad de comprender, comprobar y mantener. La utili- 
zación de un número limitado de construcciones lógicas 
también contribuye a un proceso de comprensión huma- 


E Condición 


Siguiente 
tarea 


Parte 
entonces 


Secuencia Si entonces si-no 
nn (iFf-then-else) 
Condición 
del caso 
Sin Tarea 
J Parte de bucle 


F 


Condición 
Mientras- h 
Mirna! hacer Yebucle eecerir-hasta 
(do-while) (repeat-until) 
Según-sea (seleción) Repetición 


FIGURA 16.1. Construcciones en diagrama de flujo. 
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na que los psicólogos denominan fragmentación (tro- 
ceado o chunking). Para entender este proceso, consi- 
deremos la manera de leer esta página. Las letras no se 
leen individualmente: más bien, se reconocen formaso: 
trozos de letras que forman palabras o frases. Las cons* 
trucciones estructuradas son fragmentos lógicos que: 
permiten al lector reconocer elementos procediment 
les de un módulo en lugar de leer el diseño o el código: 
línea a línea. La comprensión mejora cuando se encuené 
tran patrones fácilmente reconocibles. 


16.1.1. Notación gráfica del diseño 


«Una imagen vale más que mil palabras», pero es impor: 
tante saber qué imagen y qué 1.000 palabras. Es incues- 
tionable que herramientas gráficas, tales como diagramas 
de flujo o diagramas de cajas, proporcionan formas grá- 
ficas excelentes que representan datos procedimentales 
fácilmente. 


YN 
a 


CLAVE 


la programaciónestructurado proporciona 
los modeloslógicos y útilespara el diseñador. 


El diagrama de flujo es una imagen bastante senci- 
lla. Mediante la utilización de una caja se indica un paso 
del proceso. Un rombo representa una condición lógi- 
ca y las flechas indican el flujo de control. La Figura 
16.1 ilustra tres construccionesestructuradas.La secuen- 
cia se representa como dos cajas de procesamiento 
conectadas por una línea (flecha) de control. La condi- 
ción, llamada también si-entonces-si no, se representa 


Siguiente 
tarea 


Primera 
Parte 
Si-entonces 


Condición : Ñ 


Tarea 
de bucle 


Condición 
de bucle 


FIGURA 16.2. Construcciones anidadas. 
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mediante el símbolo del rombo de decisión que, si es 
cierto, provoca el procesamiento de la parte entonces, 
y, s1es falso, invoca el procesamiento de laparte si-no. 
La repetición se representa mediante dos formas lige- 
ramente diferentes. El mientras-hacer prueba una con- 
dición y ejecuta una tarea de bucle repetidamente 
siempre que la condición siga siendo verdad. Un repe- 
tir-hasta primero ejecuta la tarea de bucle, después prue- 
ba la condición y repite la tarea hasta que la condición 
falla. La construcción de selección (según_sea) que se 
muestra en la figura realmente es una extensión de si- 
entonces-si_no. Un parámetro se prueba por decisiones 
sucesivas hasta que ocurre una condición verdadera y 
se ejecuta el camino de procesamiento asociado. 

Las construcciones estructuradas pueden anidarse 
unas en otras como muestra la Figura 16.2. En esta Figu- 
ra, un repetir-hasta forma la parte then de un si-enton- 
ces-si-no (mostrada déntro de la línea discontinua 
exterior). Otro 1f-then-else forma la parte si-no de la pri- 
mera condición. Finalmente la condición propiamente 
dicha se convierte en un segundo bloque en una secuen- 
cia. Anidando construcciones de esta manera, se puede 
desarrollar un esquema lógico complejo. Se debería des- 
tacar que cualquiera de los bloques de la Figura 16.2 
podría hacer referenciaa otro módulo, logrando por tan- 
to la estratificación procedimental que conlleva la estruc- 
tura del programa. 


loop 


las construcciones de programación estructurado 
deberán facilitar la comprensióndeldiseño. Es correcto 
soltarlos, si utilizarlossin «saltarlas» da como resultado 
uno complejidad innecesaria 


En general, la utilización dogmática de construccio- 
nes estructuradas exclusivamente puede introducir ine- 
ficiencia cuando se requiere salir de un conjunto de 
bucles anidados o condiciones anidadas. Lo que es más 
importante, una complicación adicional de todas las 
pruebas lógicas a lo largo del camino de salida puede 
oscurecer el flujo de control del software, aumentar la 
posibilidad de error y tener un impacto negativo en su 
lectura y mantenimiento. ¿Qué podemos hacer? 

"El diseñador dispone de dos opciones: (1) la repre- 
sentación procedimental se rediseña de manera que la 
«rama de escape» no sea necesaria en una posición ani- 
dada en el flujo de control; o (2) las construcciones 
estructuradas se salten de una manera controlada; esto 
es, se diseña una rama restringida fuera del flujo anida- 
do. La opción 1 es obviamente el enfoque ideal, pero la 
opción 2 se puede implantar sin romper el espíritu de la 
programación estructurada [KNU”7S5]. 

Otra herramienta de diseño gráfico, el diagrama de 
cajas, surgió del deseo de desarrollar una representa- 
ción de diseño procedimental que no permitiera la vio- 
lación de las construcciones estructuradas. Desarrollada 
por Nassi y Schneiderman [NAS73] y ampliada por 
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CAFILULU 10 MENO A NIVEL DECOMPONENTES 


Chapin [CHA74], los diagramas (también denomina- 
dos diagramas Nassi-Schneiderman, diagramas N-S O 
diagramas Chapin) tienen las características siguien- 
tes: (1) dominio funcional (es decir, el alcance de una 
repetición O de un si-entonces-si—-no) bien definido y 
claramente visible como representación gráfica; (2) la 
transferencia arbitraria de control es imposible; (3) el 
alcance de los datos locales y/o generales se puede deter- 
minar fácilmente y (4)la recursividad es fácil de repre- 
sentar. 


e Condición 


Primera tarea 


Siguiente tarea 


Parte 
entonces 


Siguiente tarea +1. 


Secuencia Si-entonces-si-no 


"Condición de bucle 
a Parte 
repetir hasta 
(repeat until) 
Parte 
hacer mientras 
(do while) 


Condición de bucle 


Repetición 


cendición según=sea (case) 


Selección 


FIGURA 16.3. Construcciones de diagramas de capas. 


La representación gráfica de construcciones estruc- 
turadas mediante diagramas de cajas se ilustra en la 
Figura 16.3. El elemento fundamental del diagrama es 
la caja. Para representar una secuencia, se conectan dos 
cajas seguidas. Para representar un si-entonces-si-no, 
la condición va seguida de una caja parte si-entonces y 
una parte sino. La repetición se dibuja con un límite 
que encierra el proceso (parte hacer-mientras o parte 
repetir-hasta) que se va a repetir. Finalmente, la selec- 
ción se representa mediante la forma gráfica mostrada 
en la parte inferior de la figura. 
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INGENIERÍA DEL SOFTWARE. un ENFUQUE PRA LIV 


MS 


Tontolos diagramas de flujo como los diagramas 

de cojos yo no se utilizan tonto como antes. En general, 
se deberían utilizar puro documentar o evaluar el diseño 
encasos específicos, no parorepresentar todo unsistema. 


Al igual que los diagramas de flujo, un diagrama de 
cajas está estratificado en múltiples páginas a medida 
que se refinan los elementos de procesamiento de un 
módulo. Una «llamada» a un módulo subordinado se 
puede representar mediante una caja con el nombre del 
módulo encerrado en un óvalo. 


16.1.2. Notación tabular de diseño 


En muchas aplicaciones de software, puede ser necesa- 
rio un módulo que evalúe una combinación compleja 
de condiciones y que seleccione las acciones basadas 
en esas condiciones. Las tablas de decisión proporcio- 
nan una notación que convierte acciones y condiciones 
(descritasen la narración del procesamiento)en una for- 
ma tabular. Es difícil que la tabla se pueda interpretar 
mal, e incluso es posible utilizarla como entrada legi- 
ble por la máquina para un algoritmo dirigido por una 
tabla. En un estudio completo de esta herramienta de 
diseño, Ned Chapin afirma [HUR83]: 


Reglas 


2 
Y| | WyY| | | 

A AE 
ICA 


Acciones 


acción n.* 1 PA 
acción n.* 2 MIKA 
O E 


acción n.? 4 
acción n.* 5 


FIGURA 16.4. Nomenclatura de la tabla de decisión. 


Algunas herramientas de software antiguas se combinan 
bien con otras herramientasnuevas y técnicasde ingenieríadel 
software. Las tablas de decisión son un ejemploexcelente. Fue- 
ron las que precedieron a la ingeniería del software hace casi 
una década, pero encajaron tan bien con la ingeniería del soft- 
ware que podrían haberse diseñado con tal propósito. 


Cons: 


Utilice uno tabla de decisión cuando dentro 
de un componente se combine un conjunto 


CORRO de ts y AR US. 


En la Figura 16.4 se ilustra la organización de la tabla 
de decisión y se divide en cuatro secciones. El cuadrante 
superior izquierdo contiene una lista de todas las con- 
diciones. El cuadrante inferior contiene una lista de todas 
las acciones posibles basándose en combinacionesde 
las condiciones. Los cuadrantes de la derecha forman 
una matriz que indica las combinaciones de las condi- 
ciones y las correspondientes acciones que se han de 
producir para cada combinación específica. Por tanto, 
cada columna de la matriz puede interpretarse comouna 
regla de procesamiento. 

Para desarrollar una tabla de decisión se aplican los 
siguientes pasos: 


1. Hacer una lista de todas las acciones que pueden aso- 
ciarse con un procesamiento específico (o módulo). 


2. Hacer una lista de todas las condiciones (o decisio- 
nes) durante la ejecución del procesamiento. 


3. Asociar conjuntos específicos de condiciones con 
acciones específicas, eliminando combinaciones 
imposibles de condiciones; alternativamente, desa- 
rrollar cualquier permutación posible de combina- 
ciones. 


4. Definir reglas indicando qué acción O acciones ocu- 
rren para un conjunto de condiciones. 


¿Cómo se puede construir 
una tabla de decisiones? 


Para ilustrarel empleo de una tabla de decisión tome- 
mos en consideración el siguiente extracto de una des- 
cripción procedimental para un sistema de facturación 
de un servicio público: 

Si la cuenta del cliente se factura utilizando un métodode 
tarifas fijo, se establece un cargo mensual mínimo para con- 
sumos menores de 100kWHh (kilovatios/hora). En los demás 
casos, la facturación por computadora aplica la tarifa A. Sin 
embargo, si la cuenta se factura empleando un método de fac- 
turación variable, se aplicará la tarifa A para consumos por 
debajo de 100kWh, con un consumo adicional facturado de 
acuerdo con la tarifa B. 


La Figura 16.5 ilustra una representación de tabla de 
decisión de la descripción anterior. Todas y cada una de 
las cinco reglas indican una condición de las cinco via- 
bles (esto es, en el contexto de este procedimiento una 
<V» (verdadera) no tiene sentido ni en la cuenta de tar+ 
fa fija ni en la variable, por tanto esta condición se omi- 
te). Como regla general, la tabla de decisión puede 
utilizarse eficazmente para complementar otras nota- 
ciones de diseño procedimental. 


16.1.3. Lenguaje de diseño de programas 

El lenguaje de diseño de programas (LDP),también 
denominado lenguaje estructurado opseudocódigo, es 

«un lenguaje rudimentario en el sentido de que utiliza 
el vocabulario de un lenguaje (por ejemplo, el Inglés), 
YAMI AIDA he SIDÍSIO ES, VNÍEABLAR SUL 
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turado de programación)>PpCAI175]. En este capítulo se 
utiliza LDP como referencia genérica de un lenguaje de 
diseño. 

A primera vista LDP se parece a un lenguaje de pro- 
gramación moderno. La diferencia entre éste y un ver- 
dadero lenguaje de programación radica en el empleo 
de texto descriptivo (por ejemplo, Inglés) insertado 
directamente dentro de las sentenciasde LDP. Dado que 
se utiliza texto descriptivo insertado directamente en 
una estructura sintáctica,este lenguaje no se puede com- 
pilar (al menos por ahora). Sin embargo, las herramientas 
LDP que existen actualmente convierten LDP en un 
«esquema» de lenguaje de programación, y/o repre- 
sentación gráfica (por ejemplo, un diagrama de flujo de 
diseño). Estas herramientas también producen mapas 
anidados, un índice de operación de diseño, tablas de 
referencias cruzadas, y más diversidad de información. 


Reglas 
Condiciones 112131415 u1 


Cuenta de tarifa fija 


Cuenta de tarifa variable 


Consumo < 100kWh 
Consumo > 100kWh 


Facturación tarifa A 


,»Facturacióntarita B 


Otro tratamiento MA Y 


FIGURA 16.5. Tabla de decisión resultante. 


Un lenguaje de diseño de programas puede ser una 
simple transposición de un lenguaje tal como Ada o €, 
Alternativamente, puede ser un producto comprado 
específicamente para el diseño procedimental. 


Cionsuo fp 


Sería una buena idea utilizar un lenguaje 

de programación cama base para el LDP 

Esto horá posible generar un esquemade código 
(mezclado cantexto) a medida que se lleva 
acabo el diseño a nivel de componentes. 


Una sintaxis básica LDP deberá incluir construccio- 
nes para la definición de subprogramas, descripción de 
lainterfaz, declaración de datos, técnicas para la estruc- 
turación de bloques, construcciones de condición, cons- 
trucciones repetitivas y construcciones de E/S. El 
formato y la semántica de estas construcciones LDP se 
presentan en la sección siguiente. 
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Hay que destacar que LDP se puede ampliar de 
manera que incluya palabras clave para procesos mul- 
titarea y/o concurrentes, manipulación de interrupcio- 
nes, sincronización entre procesos y muchas otras 
características. Los diseños de aplicaciones para los que 
se utiliza LDP deberán dictar la forma final que tendrá 
el lenguaje de diseño. 


16,1,4, Un ejemplo de LDP 


Para ilustrar el empleo de LDP presentamos un ejem- 
plo de diseño procedimental para el software del siste- 
ma de seguridad HogarSeguro comentado en capítulos 
anteriores. El sistema HogarSeguro en cuestión vigila 
las alarmas de detección de fuego, humo, ladrones, agua 
y temperatura (por ejemplo, la ruptura del sistema de 
calefacción durante la ausencia del propietario en invier- 
no); hace saltar el sonido de la alarma, y llama al ser- 
vicio de vigilancia generando un mensaje de voz 
sintetizada. En el LDP que se muestra a continuación, 
se ilustran algunas de las construcciones importantes 
señaladas en secciones anteriores. 

Hay que recordar que LDP no es un lenguaje de pro- 
gramación. El diseñador hace una adaptación cuando 
lo requiere y sin preocuparse de errores de sintaxis. Sin 
embargo, se deberá revisar el diseño del software de 
vigilancia (¿se observa algún problema?) y refinarlo 
antes de escribirse. El LDP siguiente define una elabo- 
ración de diseño procedimental para el componente de 
monitor de seguridad. 


PROCEDURE seguridad.monitor; 

INTERFACE RETURNS sistema.estado; 

TYPE señal IS STRUCTURE DEFINED 
nombre IS STRING LENGTH VAR; 
dirección IS HEX dispositivo localización; 
límite. valor IS superior límite SCALAR; 
mensaje 15 STRING LENGTH VAR; 

END señal TYPE; 

TYPE sistema.estado IS BIT (4); 

TYPE alarma.tipo DEFINED; 
humo.alarma IS INSTANCE OF señal; 
fuego.alarma IS INSTANCE OF señal; 
agua.alarma IS INSTANCE OF señal; 
temp.alarma IS INSTANCE OF señal; 
ladrón. alarma IS INSTANCE OF señal; 


TYPE teléfono.número IS are código + 7 -dígito 
número; 


inicializar todos sistemas puertos y reinicializar 
todo hardware; 
CASE OF control .panel.interruptores (cps) ; 
WHEN cps “test ' SELECT 
CALL alarma PROCEDURE WITH “activado”para co 
probación. tiempo en segundos; 
WHEN cps = “alarma-desactivada”SELECT 
CALL alarma PROCEDURE WITH “desactivada”; 
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WHEN cps = “nuevo. límite. temp" SELECT 
CALL teclado. entrada PROCEDURE; 

WHEN cps “ladrón alarma, desactivada" SELECT 
desactivar señal [ladrón.alarma]; 


DEFAULT ninguno; 
ENDCASE 
REPEAT UNTIL activar. interruptor es desactivado 
reinicializar todos señal .valores e interruptores; 
DO FOR alarma.tipo humo, fuego, agua, temp, 
ladrón; 
READ dirección[alarma.tipo] señal.valor; 
IF señal.valor > límite falarma.tipo] 
THEN teléfono.mensaje = mensajelalarma.tipo); 


establecer alarma.timbre en “activada"“para 
alarma. tiemposegundos; 


PARBEGIN 
CALL alarma PROCEDURE WITH “activada”,alarr 
ma. tiempo en segundos; 
CALL teléfono PROCEDURE WITH mensaje [alar« 
ma. tipo], teléfono número; 
ENDPAR 
ELSE bifurcación 
ENDIF 
ENDFOR 
ENDREP 
END seguridad.monitor 


Hay que destacar que el diseñador del procedimientt 
del monitor de seguridad ha utilizado una construcción 
nueva PARBEGZN ... ENDPAR la cual especifica un blo- 
que paralelo. Todas las tareas especificadasdentro del blo- 
que PARBEGZN se ejecutan en paralelo. En este caso, no 
se toman en consideraciónlos detalles de implementación, 


En la sección anterior se han presentado varias técnicas 
diferentes para representar un diseño procedimental. Se 
puede establecer una comparación teniendo la premisa 
de que cualquier notación para el diseño procedimen- 
tal, si se utiliza correctamente, puede ser una ayuda 
incalculable para el proceso de diseño; por el contrario, 
aun con la mejor notación, si ésta se aplica mal, dismi- 
nuye su entendimiento. Teniendo en cuenta lo anterior, 
es momento de examinar los criterios que se pueden 
aplicar para comparar las notaciones de diseño. 

La notación de diseño deberá llevamos a una repre- 
sentación procedimental fácil de entender y de revisar. 
Además, la notación deberá mejorar la habilidad de 
«codificaren» para que el código se convierta de hecho 
en un subproducto natural de diseño. Finalmente, la 
representación de diseño deberá ser fácil de mantener 
para que el diseño sea siempre una representación 


correcta del programa. 
2 ¿Cuáles son los criterios que 
se utilizan para evaluar 
notaciones de diseño? 


Dentro del contexto de las características generales 
que se describieron anteriormente se han establecido 
los siguientes atributos de notaciones de diseño: 


Modularidad. Una notación de diseño deberá sopor- 
tar el desarrollo del software modular y proporcionar 
un medio para la especificación de la interfaz. 


Simplicidad general. Una notación de diseño debe- 
rá ser relativamente simple de aprender, relativamente 
fácil de utilizar y en general fácil de leer. 


Facilidad de edición. Es posible que el diseño 
procedimental requiera alguna modificación a medi- 
da que el proceso de software avanza. La facilidad 
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con la que un diseño se puede editar ayudará a sim- 
plificar todas y cada una de las tareas de la ingenie- 
ría del software. 


Legibilidad para la computadora. Una notación 
que se puede introducir directamente en un sistema de 
desarrollo basado en computadora ofrece ventajas sig- 
nificativas. 


Capacidad de mantenimiento. El mantenimiento 
del software es la fase más costosa del ciclo de vida del 
software. El mantenimiento de la configuración del soft- 
ware casi siempre lleva al mantenimiento de la repre- 
sentación del diseño procedimental. 


Cumplimiento de las estructuras. Ya se han des- 
crito las ventajas de un enfoque de diseño que utiliza 
conceptos de programación estructurada. Una notación 
de diseño que hace cumplir solo la utilización de cons- 
trucciones estructuradas conduce a la práctica de un 
buen diseño. 


Proceso automático. Un diseño procedimental con- 
tiene la información que se puede procesar para que el 
diseñador pueda observar otra vez y mejorar la correc- 
ción y calidad de un diseño. Dicha observación puede 
mejorarse con informes que provengan de herramien- 
tas de diseño de software. 


Representación de datos. La habilidad de repre- 
sentar datos locales y globales es un elemento esencial 
del diseño detallado. Una notación de diseño ideal sería 
la representación directa de los datos. 


Verificación de la lógica. La verificación automáti- 
ca de la lógica del diseño es el objetivoprimordial duran- 
te las pruebas del software. Una notación que mejora la 
habilidad de verificar la lógica mejora enormementelo 
aceptable de las pruebas. 
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Habilidad de «codificar en». La tarea de ingenie- 
ría del software que va a continuación del diseño a nivel 
decomponenteses la generación de códigos. Una nota- 
ción que puede convertirse fácilmente en código fuen- 
tereduce esfuerzos y errores. 

Una pregunta que surge naturalmente de cualquier 
estudio de notaciones de diseño es: «¿Cuál es realmen- 
tela mejor notación según los atributos que se han esta- 
blecido anteriormente?» La respuesta sería totalmente 
subjetiva y abierta a debate. Sin embargo, parece ser 
que el lenguaje de diseño de programas ofrece la mejor 
combinación de características. LDP puede insertarse 
directamente en listados de fuentes, en mejoras de docu- 
mentación y al hacer que el mantenimiento del diseño 
sea menos difícil. La edición se puede llevar a cabo 
mediante cualquier editor de texto O sistema de proce- 
samiento de texto; los procesadores automáticosya exis- 


Iamarvar us "“."EÑO A NIVEL DE COMPONENTES 


ten, y el potencial de «generar códigos automáticos»es 
bueno. 

Sin embargo, no se puede decir que la notación 
de diseños sea necesariamente inferior a LDP o que 
«sea buena» en atributos específicos. Muchos dise- 
ñadores prefieren la naturaleza pictórica de los día- 
gramas de flujo y de los diagramas de bloques dado 
que proporcionan alguna perspectiva sobre el flujo 
de control. El contenido tabular preciso de las tablas 
de decisión es una herramienta excelente para las 
aplicaciones controladas por tablas. Y muchas otras 
representaciones de diseño (por ejemplo, véase 
[PET8 1], [SOM96)), que no se presentan en este 
libro, ofrecen sus propias ventajas. En el análisis 
final, la selección de una herramienta de diseño pue- 
de depender más de factores humanos [CUR85] que 
de atributos técnicos. 


El proceso de diseño acompaña a una secuencia de acti- 
vidades que reducen lentamente el nivel de abstracción 
con el que se representa el software. El diseño a nivel 
de componentes representa el software a un nivel de 
abstracción muy cercano al código fuente. 

Aun nivel de componentes, el ingeniero del software 
debe representar estructuras de datos, interfaces y algo- 
ritmos con suficiente detalle como para servir de guía 
en la generación de códigos fuente de lenguajes de pro- 
gramación. Para conseguirlo, el ingeniero utiliza una de 


las notaciones de diseño que representa los detalles a 
nivel de componentes o bien en formatos gráficos, tabu- 
lares O basados en texto. 

La programación estructurada es una filosofía de 
diseño procedimental que restringe el número y tipo de 
construcciones lógicas que se utilizan para representar 
el dato algorítmico. El objetivo de la programación 
estructurada es ayudar a que el diseñador defina algo- 
ritmos menos complejos y por tanto más fáciles de leer, 
comprobar y mantener. 


[BOH66] Bohm, C., y G. Jacopini,«Flow Diagramas, Turing 
Machines and Languages with only two Formation Rules», 
CACM, vol. 9, n.* 5, Mayo 1966, pp. 366-371. 


[CAI75] Caine, S., y K. Gordon, «PDL —A Tool for Soft- 
ware Design», in Proc. National Computer Conference, 
AFIPS Press, 1975,pp. 271-276. 


[CHA74] Chapin, N., «A New Format for Flowcharts», Soft- 
ware —Practice and Experience, vol. 4, n.2 4, 1974, pp. 
341-357. 


[DIJ65] Dijkstra, E., «Programming Considered as a Human 
Activity», in Proc. 1965 IFIP Congress, North Holland 
Publishing Co., 1965. 


[DIJ72] Dijkstra, E., «The Humble Programmer», 1972ACM 
Turing Award Lecture, CACM, vol. 15,n,* 10, Octubre 
1972, pp. 859-866. 
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[DIJ76] Dijkstra, E., «Structure Programming», Software 
Engineering, Concepts and Techniques (3. Buxton et al., 
eds.), Van Nostrand-Reinhold, 1976. 


[HUR83] Hurley, R.B., Decision Tables in Software Engi- 
neering, Van Nostrand Reinhold, 1983. 


[LIN79] Linger, R.C, H. D. Mills y B.L Witt, Estructured 
Programming, Addison-Wesley, 1979 


[NAS73] Nassi, L, y B, Shneiderman, «Flowchart Techni- 
ques for Structured Programming», SIGPLAN Notices, 
ACM, Agosto 1973. 


[PET81] Peters, L.J., Software Design: Methods and Tech- 
niques, Yourdon Press, Nueva York, 1981. 


[SOM96] Sommerville, I., Software Engineering, 5.2 ed., 
Addison-Wesley, 1996. 
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asi A a a 


16.1. Seleccione una parte pequeña de un programa que ya 
exista (aproximadamente de 50-75 líneas de código). Aísle las 
construcciones de programación estructurada dibujando cajas 
alrededor de ellas en el código fuente. ¿Existen construccio- 
nes dentro del pasaje del programa que violen la filosofía de 
programación estructurada? Si fuera así, vuelva a diseñar el 
código para adaptarlo a las construcciones de programación 
estructurada. Si no fuera así, ¿Qué se puede destacar en las 
cajas que acaba de dibujar? 


16.2. Todos los lenguajes de programación modernos imple- 
mentan las construcciones de programación estructurada. Pro- 
porcione ejemplos de tres lenguajes de programación. 


16.3. ¿Por qué es importante la «fragmentación» durante el 
proceso de revisión de diseño a nivel de componentes? 


Los problemas 16.4-16.12 se pueden representar en una (o 
más) notaciones de diseño procedimentales presentadas en 
este capítulo. Su profesor puede asignar notaciones de diseño 
específicas a problemas concretos. 


16.4. Desarrolle un diseño procedimental para los compo- 
nentes que implementan las ordenaciones siguientes: Shell- 
Metzner; heapsort (ordenación del montículo). Si no está 
familiarizado con estas ordenaciones, consulte cualquier libro 
sobre estructuras de datos. 


16.5. Desarrolle un diseño procedimental para una interfaz de 
usuario interactiva que solicite información básica acerca de 
los impuestos sobre la renta. Derive sus propios requisitos y 


suponga que todos los procesos sobre los impuestos son lle- 
vados a cabo por otros módulos. 


16.6. Desarrolle un diseño procedimental para un programa 
que acepte un texto arbitrariamente largo como entrada y ela- 
bore una lista de palabras y de su frecuencia de aparición como 
salida. 


16.7. Desarrolle un diseño procedimental de un programa que 
integre numéricamenteuna funciónf en los límites de a haciab. 


16.8. Desarrolle un diseño procedimental para una máquina 
Turing generalizada que acepte un conjunto de cuádruples 
como entrada de programa y elabore una salida según espe- 
cificación. 

16.9. Desarrolle un diseño procedimental para un programa 
que solucione el problema de las Torres de Hanoi. Muchos 
libros de inteligencia artificial estudian este problema deta- 
lladamente. 


16.10. Desarrolle un diseño procedimental para todas las par- 
tes o las partes fundamentales de un analizador sintácticopara 
un compilador. Consulte uno o más libros sobre diseño de 
compiladores. 


16.11. Desarrolle un diseño procedimental para el algoritmo 
de encriptación/descriptación que haya seleccionado. 


16.12. Escriba un argumento de una o dos páginas para la nota- 
ción de diseño procedimental que prefiera. Asegúrese de que su 
argumento abarca los criterios presentados en la Sección 162. 


El trabajo de Linger, Mills y Witt (Structured Programming- 
Theory and Practice, Addison-Wesley, 1979) sigue siendo el 
estudio definitivo sobre esta materia. El texto contiene un 
buen LDP así como estudios detallados de ramificaciones de 
la programación estructurada. Entre otros libros que se cen- 
tran en temas de diseño procedimental se incluyen los libros 
de Robertson (Simple Program Design, Boyd « Fraser Publis- 
hing, 1994), Bentley (Programming Pearls, Addison-Wes- 
ley, 1986, y More Programming Pearls, Addison-Wesley, 
1988) y Dahl, Dijkstra y Hoare (Structured Progamming, Áca- 
demic Press, 1972). 

Solo existe un número relativamente pequeño de libros 
actuales dedicado únicamente al diseño a nivel de com- 
ponentes. En general, los libros de lenguajes de progra- 
mación abordan el diseño procedimental con algún detalle, 
pero siempre en el contexto del lenguaje que se ha intro- 
ducido en este libro. Los siguientes libros son representa- 
tivos de los cientos de títulos que tienen en consideración 
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el diseño procedimental en un contexto de lenguaje de pro- 
gramación: 

Adamson, T.A., K.C. Mansfield y J,L. Antonakos, Struc- 
tured Basic Applied to Technology, Prentice Hall, 2000. 

Antonakos, J.L., y K. Mansfield, Application Program 
ming in Structured C, Prentice Hall, 1996. 

Forouzan, B.A., y R. Gilberg, Computer Science: A Struc- 
tured Programming Approach Using C++, Brooks/Cole 
Publishing, 1999, 

O”Brien, S.K., y S. Nameroff, Turbo Pascal 7: The Com- 
plete Reference, Osbome McGraw-Hill, 1993. 

Welbum, T., y W. Price, Structured Cobol: Fundamentals 
and Style, 4.2 ed., Mitchell Publishers, 1995, 

Una gran variedad de fuentes de información sobre dise- 
ño de software y temas relacionados están disponibles en 
Intemet. Una lista actualizada de referencias a sitios (luga- 
res) web que son relevantes para conceptos y métodos de dise- 
ño se pueden encontrar en http://www.pressman5.com. 
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TÉCNICAS DE PRUEBA 
DEL SOFTWARE 


NCA se dará suficiente importancia a las pruebas del software y susimplicaciones en 
la calidad del software. Citando a Deutsch [DEU79]: 


El desarrollo de sistemas de software implica una serie de actividades de producción en las que las posi- 
bilidades de que aparezca el fallo humano son enormes. Los errores pueden empezar a darse desde el pri- 
mer momento del proceso, en el que los objetivos....pueden estar especificados de forma errónea o imperfecta, 
así como [en] posteriores pasos de diseño y desarrollo...Debido a la imposibilidad humana de trabajar y 
comunicarse de forma perfecta, el desarrollo de software ha de ir acompañado de una actividad que garan- 
tice la calidad. 


Las pruebas del software son un elemento crítico para la garantía de calidad del software y 
representa una revisión final de las especificaciones, del diseño y de la codificación. 

La creciente percepción del software como un elemento del sistema y la importancia de los 
«costes» asociados a un fallo del propio sistema, están motivando la creación de pruebas minú- 
ciosas y bien planificadas. No es raro que una organización de desarrollo de software emplee 
entre el 30 y el 40 por ciento del esfuerzo total de un proyecto en las pruebas. En casos extre- 
mos, las pruebas del software para actividades críticas (por ejemplo, control de tráfico aéreo, 
control de reactores nucleares) puede costar ¡de tres a cinco veces más que el resto de los pasos 
de la ingeniería del software juntos! 


VISTAZO RÁPIDO 


¿Qué es? Una vez generado el código 


fuente, el software debe ser probado: 


para descubrir (y corregir) el máximo 
de errores posibles antes de su entre- 
ga al cliente. Nuestro objetivo es dise- 
“far una serie de casos de prueba que 
tengan una alta probabilidad de 
encontrar errores —pero ¿cómo conse- 
guirlo?— Aquí es donde aplicamos las 
técnicas de pruebas del software. Estas 
técnicas facilitan una guía sistemáti- 
ca para diseñar pruebas que: (1) com- 
¿prueben la lógica interna de los 
'. componentes software, y (2) verifiquen 
¿los dominios de entrada y salida del 
1 programa para descubrir errores en la 
funcionalidad, el comportamiento y 
rendimiento 
¿Quién lo hace? Durante las primeras 
“+ etapas de la prueba, es el ingeniero del 
— “software quien realiza todas las prue- 


bas. Sin embargo, conforme progresa 


. el proceso de prueba, losespecialistas 
- en pruebas se van incorporando. 


¿Por qué es importante? Las revisio- 


nes y otras actividadesSQA descubren 


* errores, pero no son suficientes. Cada 


vez que el programa seejecuta,el clien- 
te lo está probando. Por lotanto, debe- 
mos hacer un intento especial por 
encontrar y corregir todos los errores 
antes deentregar el programaal clien- 
te.Con el objetivode encontrarel mayor 
númeroposible de errores, las pruebas 
deben conducirse sistemáticamente. y 
los casos de prueba deben diseñarse 
utilizandotécnicas definidas. 


¿Cuáles son los pasos? El software debe 
probarse desde dos perspectivas dife-* 


rentes: (1) la lógica interna del progra- 
ma se comprueba u tiliidotécnicas de 
diseño de casos de prueba de «caja 


blanca».Los requisitos del software se 
comprueban u ti1liiotécnicasdedise- 
ño decasos de prueba de «caja negra». 


Enamboscasos, seintentaencontrarel 
mayor número de errores con la menor 


cantidad de esfuerzo y tiempo. 


¿Cuál es el producto obtenido? Se 


define y documenta un conjunto de 
casos de prueba, diseñados para com- 
probar la lógica interna y losrequisitos 
externos. Se determinan los resultados 
esperados y se guardan los resultados 
realmente obtenidos. 


¿Cómo puedo estar seguro de que lo 


he hecho correctamente? Cuan- 
do comienzas la prueba,debes cambiar 
tu punto de vista. Intenta «romper» con 
firmeza el software. Diseña casos de 
prueba de una forma disciplinada y 
revisa que dichos casos de prueba 
abarcan todo lo desarrollado. 


En este capítulo, veremos los fundamentos de las pruebas del software y las técnicas de dise- 
ño de casos de prueba. 


281 


www.elsolucionario.net 


INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRACTICO 


Las pruebas presentan una interesante anomalía para el 
ingeniero del software. Durante las fases anteriores de 
definición y de desarrollo, el ingeniero intenta construir 
el software partiendo de un concepto abstracto y llegan- 
do auna implementacióntangible. A continuación, llegan 
las pruebas. El ingenierocrea una serie de casos de prue- 
ba que intentan «demoler» el software construido. De 
hecho, las pruebas son uno de los pasos de la ingeniería 
del software que se puede ver (por lo menos, psicológi- 
camente) como destructivo en lugar de constructivo. 


ej lo bonito dif 


Los ingenieros del software son, por naturaleza, per- 
sonas constructivas. Las pruebas requieren que se des- 
carten ideas preconcebidas sobre la «corrección» del 
software que se acaba de desarrollar y se supere cual- 
quier conflicto de intereses que aparezcan cuando se 
descubran errores. Beizer [BEI90] describe eficiente- 
mente esta situación cuando plantea: 

Existe un mito que dice que si fuéramos realmente buenos 
programando, no habría errores que buscar. Si tan sólo fuéra- 
mos realmente capaces de concentrarnos, si todo el mundo 
empleara técnicas de codificación estructuradas, el diseño des- 
cendente, las tablas de decisión, si los programas seescribieran 
enun lenguaje apropiado, si tuviéramos siempre la solución más 
adecuada, entonces no habría errores. Así es el mito. Según el 
mito, existen errores porque somos malos en lo que hacemos, 
y si somos malos en lo que hacemos, deberíamossentirnoscul- 
pables por ello. Por tanto, las pruebas, con el diseño de casos 
de prueba, son un reconocimiento de nuestros fallos, lo que 
implica una buena dosis de culpabilidad. Y lo tediosas que son 
las pruebas son un justo castigoa nuestroserrores. ¿Castigados 
por qué? ¿Por ser humanos? ¿Culpables por qué? ¿Por no con- 
seguiruna perfección inhumana? ¿Por no poder distinguirentre 
lo que otro programador piensa y lo que dice? ¿Por no tener 
telepatía? ¿Por no resolver los problemas de comunicación 
humana que han estado presentes...durante cuarenta siglos? 


¿Deben infundir culpabilidadlas pruebas? ¿Son real- 
mente destructivas? La respuesta a estas preguntas es: 
¡No! Sin embargo, los objetivos de las pruebas son algo 
diferentes de lo que podríamos esperar. 


17.11. Objetivos de las pruebas 


En un excelente libro sobre las pruebas del software, 
Glen Myers [MYE79] establece varias normas que pue- 
den servir acertadamentecomo objetivosde las pruebas: 


1, La prueba es el proceso de ejecución de un programa 
con la intención de descubrir un error. 
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2. Un buen caso de prueba es aquel que tiene una alta 
probabilidad de mostrar un error no descubierto hasta 
entonces. 


3. Una prueba tiene éxito si descubre un error no detec- 
tado hasta entonces. 
¿Cuál es nuestro primer 


9 objetivo cuando probamos 
el software? 


Los objetivos anteriores suponen un cambio dramá- 
tico de punto de vista. Nos quitan la idea que, normal- 
mente, tenemos de que una prueba tiene éxito si no 
descubre errores. 

Nuestro objetivo es diseñar pruebas que sistemática- 
mente saquen a la luz diferentes clases de errores, hacién- 
dolo con la menor cantidad de tiempo y de esfuerzo. 

Si la prueba se lleva a cabo con éxito (de acuerdo cn 
el objetivo anteriormente establecido),descubriráerrores 
en el software. Como ventaja secundaria, la prueba 
demuestra hasta qué punto las funciones del software pare 
cen funcionarde acuerdo con las especificaciones y pare- 
cen alcanzarse los requisitos de rendimiento. Además, los 
datos que se van recogiendo a medida que se lleva a cabo 
la prueba proporcionan una buena indicación de la fiabi- 
lidad del software y, de alguna manera, indican la calidad 
del softwarecomo un todo. Pero, la prueba no puede ase- 
gurar la ausencia de defectos; sólo puede demostrar que 
existen defectos en el software. 


Ú 


17.1.2. Principios de las pruebas 


Antes de la aplicación de métodos para el diseño de 
casos de prueba efectivos, un ingeniero del software 
deberá entender los principios básicos que guían las 
pruebas del software. Davis [DAV95] sugiere un con- 
junto' de principios de prueba que se han adaptado para 
usarlos en este libro: 


. A todas las pruebas se les debería poder hacer un 
seguimiento hasta los requisitos del cliente. Como 
hemos visto, el objetivo de las pruebas del software 
es descubrirerrores. Se entiende que los defectosmás 
graves (desde el punto de vista del cliente) son aque- 
llos que impiden al programa cumplir sus requisitos. 


1 Aquí se presenta sólo un pequeño subconjunto de los principios de 
ingeniería de pruebas de Davis. Para obtener más información, vea 
[DAV96]. 
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+ Las pruebas deberían planificarse mucho antes de 
que empiecen. La planificación de las pruebas (Capí- 
tulo 18) pueden empezar tan pronto como esté com- 
pleto el modelo de requisitos. La definición detallada 
de los casos de prueba puede empezar tan pronto 
como el modelo de diseño se ha consolidado. Por 
tanto, se pueden planificar y diseñar todas las prue- 
bas antes de generar ningún código. 

El principio de Pareto es aplicable a la prueba del 
software. Dicho de manera sencilla, el principio de 
Pareto implica que al 80 por 100 de todos los erro- 
res descubiertos durante las pruebas se les puede 
hacer un seguimiento hasta un 20 por 100 de todos 
los módulos del programa. El problema, por 
supuesto, es aislarestos módulos sospechosos y pro- 
barlos concienzudamente. 

Las pruebas deberían empezarpor «lo pequeño» y 
progresar hacia «lo grande». Las primeras pruebas 
planeadas y ejecutadas se centran generalmente en 
módulos individuales del programa. A medida que 
avanzan las pruebas, desplazan su punto de mira en 
un intento de encontrar errores en grupos integrados 
de módulos y finalmente en el sistema entero (Capí- 
tulo 18). 


No sonposibles las pruebas exhaustivas. El número 
de permutaciones de caminos para incluso un pro- 
grama de tamaño moderado es excepcionalmente 
grande (vea la Sección 17.2 para un estudio más 
avanzado). Por este motivo, es imposible ejecutar 
todas las combinaciones de caminos durante las prue- 
bas. Es posible, sin embargo, cubrir adecuadamente 
la lógica del programa y asegurarse de que se han 
aplicado todas las condiciones en el diseño a nivel 
de componente. 


Para ser más eficaces, laspruebas deberían ser rea- 
lizadaspor un equipo independiente. Por «mas efi- 
caces» queremosreferirnos a pruebas con la más alta 
probabilidad de encontrar errores (el objetivo princi- 
pal de las pruebas). Por las razones que se expusie- 
ron anteriormenteen este capítulo, y que se estudian 
con más detalle en el Capítulo 18, el ingeniero del 
software que creó el sistema no es el más adecuado 
para llevar a cabo las pruebas para el software. 


17.13, Facilidad de prueba 


En circunstancias ideales, un ingeniero del software 
diseña un programa de computadora, un sistema o un 
producto con la «facilidad de prueba» en mente. Esto 
permite a los encargados de las pruebas diseñar casos 
de prueba más fácilmente. Pero, ¿qué es la «facilidad 
de prueba» James Bach* describe la facilidad de prue- 
ba de la siguiente manera: 


2 Los siguientes párrafos son copyright de James Bach, 1994,y se han 
adaptado de una página de Intemet que apareció inicialmente en el 
grupo de noticias comp.software-eng. Este material se ha usado con 
permiso. 
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La facilidad de prueba del softwarees simplemente la 
facilidad con la que se puede probar un programa de com- 
putadora. Como la prueba es tan profundamente difícil, 
merece la pena saber qué se puede hacer para hacerlo más 
sencillo. A veces los programadores están dispuestos a 
hacer cosas que faciliten el proceso de prueba y una lista 
de comprobación de posibles puntos de diseño, caracte- 
rísticas, etc., puede ser útil a la hora de negociar con ellos. 


Referencia 


Un útil documento titulado ((Perfeccionando la facilidad 
de la prueba del software» puede encontrarseen: 
www.stlabs,com/newsletters/testnet /docs/testabikity.htm. 


Existen, de hecho, métricas que podrían usarse para 
medir la facilidad de prueba en la mayoría de sus aspec- 
tos. Á veces, la facilidad de prueba se usa para indicar 
lo adecuadamente que un conjunto particular de prue- 
bas va a cubrir un producto. También es empleada por 
los militares para indicar lo fácil que se puede compro- 
bar y reparar una herramientaen plenas maniobras. Esos 
dos significadosno son lo mismo que «facilidadde prue- 
ba del software». La siguiente lista de comprobación 
proporciona un conjunto de características que llevan a 
un software fácil de probar. 


Operatividad. «Cuanto mejor funcione, más efi- 
cientemente se puede probar.» 
El sistema tiene pocos errores (los errores añaden 
sobrecarga de análisis y de generación de informes 
al proceso de prueba). 


Ningún error bloquea la ejecución de las pruebas 


El producto evoluciona en fases funcionales (per- 
mite simultanear el desarrollo y las pruebas). 


Observabilidad.«Lo que ves es lo que pruebas.» 
Se genera una salida distinta para cada entrada. 
Los estados y variables del sistema están visibles o 
se pueden consultar durante la ejecución. 


Los estados y variables anteriores del sistema están 
visibles O se pueden consultar (por ejemplo, regis- 
tros de transacción). 


Todos los factores que afectan a los resultados están 
visibles. 


Un resultado incorrecto se identifica fácilmente. 


Los errores internos se detectan automáticamente a 
través de mecanismos de auto-comprobación. 


Se informa automáticamente de los errores internos. 


El código fuente es accesible. 
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5 
a 
dave 


«Lo facilidad de prueba» ocurre como el resultadode 

un buen diseño. El diseño de datos, de la arquitectura, 
delos interfacesy de los componentes de detalle pueden 
facilitar lo prueba o hacerlo más difícil. 


Controlabilidad. «Cuanto mejor podamos contro- 
lar el software, más se puede automatizar y optimizar.» 


Todos los resultados posibles se pueden generar a 
través de alguna combinación de entrada. 


Todo el código es ejecutable a través de alguna com- 
binación de entrada. 

El ingeniero de pruebas puede controlar directamente 
los estados y las variables del hardware y del software. 
Los formatos de las entradas y los resultados son 
consistentes y estructurados. 

Las pruebas pueden especificarse, automatizarse y 
reproducirse convenientemente. 

Capacidad de descomposición. «Controlando el 
ámbito de las pruebas, podemos aislar más rápidamente 
los problemas y llevar a cabo mejores pruebas de regre- 
sión.» 

El sistema software está construido con módulos 
independientes. 

Los módulos del software se pueden probar inde- 
pendientemente 


Simplicidad. «Cuanto menos haya que probar, más 
rápidamente podremos probarlo.» 
Simplicidad funcional (por ejemplo, el conjunto de 
características es el mínimo necesario para cumplir 
los requisitos). 
Simplicidad estructural (por ejemplo, la arquitectura 
es modularizada para limitarla propagación de fallos). 
Simplicidad del código (por ejemplo, se adopta un 
estándar de código para facilitar la inspección y el 
mantenimiento). 


Estabilidad. «Cuanto menos cambios, menos inte- 
rrupciones a las pruebas.» 
Los cambios del software son infrecuentes. 


Los cambios del software están controlados. 


Los cambios del software no invalidan las pruebas 
existentes. 
El software se recupera bien de los fallos. 


Facilidad de comprensión. «Cuanta más informa- 


ción tengamos, más inteligentes serán las pruebas.» 
+. El diseño se ha entendido perfectamente. 
+ Las dependencias entre los componentes internos, 
externos y compartidos se han entendido perfectamente. 
Se han comunicado los cambias del diseño. 

La documentación técnica es instantáneamente 


accesible. 
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La documentación técnica está bien organizada. 
La documentación técnica es específica y detallada. 
La documentación técnica es exacta. 


Los atributos sugeridos por Bach los puede emplear 
el ingeniero del software para desarrollar una configu- 
ración del software (por ejemplo, programas, datos y 
documentos) que pueda probarse. 


¿Cuales son las características 
de una «buena» prueba? 


¿Y qué pasa con las pruebas propias? Kaner, Falk y 
Nguyen [KAN93] sugieren los siguientes atributos de 
una «buena» prueba: 


1. Una buena prueba tiene una alta probabilidad de 
encontrar un error. Para alcanzar este objetivo, el res- 
ponsable de la prueba debe entender el software e 
intentar desarrollar una imagen mental de cómo 
podría fallar el software. 

. Una buena prueba no debe serredundante. El tiempo 
y los recursos para las pruebas son limitados. No hay 
motivo para realizar una prueba que tiene el mismo 
propósito que otra. Todas las pruebas debenan tener 
un propósito diferente (incluso si es sutilmente dife- 
rente). Por ejemplo, un módulo del software de 
HogarSeguro (estudiadoen anteriores capítulos)está 
diseñado para reconocer una contraseña de usuario 
para activar o desactivar el sistema. En un esfuerzo 
por descubrir un error en la entrada de la contraseña, 
el responsable de la prueba diseña una serie de prue- 
bas que introducen una secuencia de contraseñas. Se 
introducen contraseñas válidas y no válidas (secuen- 
cias de cuatro números) en pruebas separadas. Sin 
embargo, cada contraseña válida/no válida debería 
analizar un modo diferente de fallo. Por ejemplo, la 
contraseña no válida 1234 no debería ser aceptada 
por un sistema programado para reconocer 8080 como 
la contraseña correcta. Si 1234es aceptada, tenemos 
presente un error. Otra prueba, digamos 1235, tendría 
el mismo propósito que 1234 y es, por tanto, redun- 
dante. Sinembargo, la entrada no válida 8081 u 8180 
tiene una sutil diferencia, intentando demostrar que 
existe un error para las contraseñas «parecidas» pero 
no idénticas a la contraseña correcta. 

. Una buena prueba debería ser «la mejor de la cose- 
cha» [KAN93]. En un grupo de pruebas que tienen 
propósito similar, las limitaciones de tiempo y recur- 
sos pueden abogar por la ejecución de sólo un sub- 
conjunto de estas pruebas. En tales casos, se debena 
emplear la prueba que tenga la más alta probabili- 
dad de descubrir una clase entera de errores. 

Una buena prueba no debería ser ni demasiado sen- 

cilla ni demasiado compleja. Aunque es posible a 

veces combinar una serie de pruebas en un caso de 

prueba, los posibles efectos secundariosde este enfo- 
que pueden enmascarar errores. En general, cada 
prueba debería realizarse separadamente. 
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El diseño de pruebas para el software O para otros pro- 
ductos de ingeniería puede requerir tanto esfuerzo como 
el propio diseño inicial del producto. Sin embargo, los 
ingenieros del software, por razones que ya hemos trata- 
do, a menudo tratan las pruebas como algo sin importan- 
cia, desarrollando casos de prueba que «parezcan 
adecuados», pero que tienen poca garantía de ser com- 
pletos. Recordando el objetivo de las pruebas, debemos 
diseñar pruebas que tengan la mayor probabilidad de 
encontrar el mayor número de errores con la mínima can- 
tidad de esfuerzo y tiempo posible. 


Cualquier producto de ingeniería (y de muchos otros 
campos) puede probarse de una de estas dos formas: (1) 
conociendo la función específica para la que fue diseña- 
do el producto, se pueden llevar a cabo pruebas que 
demuestren que cada función es completamente operati- 
va y, al mismo, tiempo buscando errores en cada función; 
(2) conociendo el funcionamientodel producto, se pue- 
den desarrollarpruebas que aseguren que «todas las pie- 
zas encajan», o sea, que la operación interna se ajusta a 
las especificaciones y que todos los componentes inter- 
nos se han comprobado de forma adecuada. El primer 
enfoque de prueba se denomina prueba de caja negra y el 
segundo, prueba de caja blanca. 


Referencia Web] 4 


La página de técnicas de prueba es una excelente fuente 
de informaciónsobre los métodos de prueba: 
www.testworks.com/News/TTN-Online / 


Cuando se considera el software de computadora, la 
prueba de caja negra serefiere a las pruebas que se lle- 
van acabo sobre la interfaz del software. O sea, los casos 
de prueba pretenden demostrar que las funciones del 
software son operativas, que la entrada se acepta de for- 
ma adecuada y que se produce un resultado correcto, 
así como que la integridad de la información externa 
(porejemplo, archivos de datos) se mantiene. Una prue- 
ba de caja negra examina algunos aspectos del modelo 
fundamental del sistema sin tener mucho en cuenta la 
estructura lógica interna del software. 

La prueba de caja blanca del software se basa en el 
minucioso examen de los detalles procedimentales. Se 
compruebanlos caminos lógicos del softwareproponiendo 
casos de prueba que ejerciten conjuntos específicos de 
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condiciones y/o bucles. Se puede examinarel «estado del 
programa» en varios puntos para determinar si el estado 
real coincide con el esperadoo mencionado. 


j CLA VE 


las pruebas de caja blanca son diseñadas después 
de que exista un diseño de componente (o código fuente). 
El detalle de la lógica del programa debe estar disponible. 


A primera vista parecería que una prueba de caja blan- 
ca muy profunda nos llevaría a tener «programas cien por 
cien correctos».Todo lo que tenemos que hacer es definir 
todos los caminos lógicos, desarrollarcasos de prueba que 
los ejerciten y evaluar los resultados, es decir, generarcasos 
de prueba que ejercitenexhaustivamentela lógica del pro- 
grama. Desgraciadamente, la prueba exhaustiva presenta 
ciertos problemas logísticos. Incluso para pequeños pro- 
gramas, el número de caminos lógicos posibles puede ser 
enorme. Por ejemplo, considere un programa de 100 líne- 
as de códigoen lenguaje C. Después de la declaración de 
algunos datos básicos, el programa contiene dos bucles 
que se ejecutan de 1 a 20 veces cada uno, dependiendo de 
las condiciones especificadas en la entrada. Dentro del 
bucle interior, se necesitan cuatro construccionesif-then- 
else. ¡Existen aproximadamente 10'* caminos posibles que 
se pueden ejecutar en este programa! 


YN 
a 


CLAVE 


No es posible una prueba exhaustiva sobre todos 
los caminos del programa, porque el número de caminos 
es simplemente demasiado grande. 


Para poner de manifiesto el significado de este núme- 
ro, supongamos que hemos desarrollado un procesador 
de pruebas mágico («mágico» porque no existe tal pro- 
cesador) para hacer una prueba exhaustiva. El procesador 
puede desarrollarun caso de prueba, ejecutarlo y evaluar 
los resultados en un milisegundo. Trabajando las 24 horas 
del día, 365 días al año, el procesador trabajaría durante 
3170 años para probar el programa. Esto irremediable- 
mente causaría estragos en la mayoría de los planes de 
desarrollo. La prueba exhaustiva es imposible para los 
grandes sistemas software. 

La prueba de caja blanca, sinembargo, no se debe dese- 
char comoimpracticable. Se pueden elegir y ejercitar una 
serie de caminos lógicos importantes. 

Se pueden comprobar las estructuras de datos más 
importantes para verificar su validez. Se pueden combi- 
nar los atributos de la prueba de caja blanca asícomo los 
de caja negra, para llegar aun método que valide la inter- 
faz del software y asegure selectivamente que el funcio- 
namiento interno del software es correcto. 
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La prueba de caja blanca, denominada a veces prueba 
de caja de cristal es un método de diseño de casos de 
prueba que usa la estructura de control del diseño pro- 
cedimental para obtener los casos de prueba. Mediante 
los métodos de prueba de caja blanca, el ingeniero del 
software puede obtener casos de prueba que (1) garan- 
ticen que se ejercita por lo menos una vez todos los cami- 
nos independientes de cada módulo; (2) ejerciten todas 
las decisiones lógicas en sus vertientes verdadera y fal- 
sa; (3) ejecuten todos los bucles en sus límites y con sus 
límites operacionales; y (4)ejerciten las estructuras inter- 
nas de datos para asegurar su validez. 

En este momento, se puede plantear un pregunta 
razonable: ¿Por qué emplear tiempo y energía preocu- 
pándose de (y probando) las minuciosidades lógicas 
cuando podríamos emplear mejor el esfuerzo asegu- 
rando que se han alcanzado los requisitos del progra- 
ma? O, dicho de otra forma, ¿por qué no empleamos 
todas nuestras energías en la prueba de caja negra? La 
respuesta se encuentra en la naturaleza misma de los 
defectos del software (por ejemplo, [JON81]): 

Los errores lógicos y las suposicionesincorrectasson 
inversamente proporcionales a la probabilidad de que 
se ejecute un camino del programa. Los errores tien- 
den a introducirse en nuestro trabajo cuando diseña- 
mos e implementamos funciones, condiciones O 
controles que se encuentran fuera de lo normal. El pro- 


cedimiento habitual tiende a hacerse más comprensi- 
ble (y bien examinado), mientras que el procesamiento 
de «casos especiales» tiende a caer en el caos. 


A menudo creemos que un camino lógico tiene pocas 
posibilidades de ejecutarse cuando, de hecho, se 
puede ejecutar de forma normal. El flujo lógico de 
un programa a veces no es nada intuitivo, lo que sig- 
nifica que nuestras suposiciones intuitivas sobre el 
flujo de control y los datos nos pueden llevar a tener 
errores de diseño que sólo se descubren cuando 
comienza la prueba del camino. 


» Los errores tipográficos son aleatorios. Cuando se 
traduce un programa a código fuente en un lenguaje 
de programación, es muy probable que se den algu- 
nos errores de escritura. Muchos serán descubiertos 
por los mecanismos de comprobación de sintaxis, 
pero otros permanecerán sin detectar hasta que 
comience la prueba. Es igual de probable que haya 
un error tipográfico en un oscuro camino lógico que 
en un camino principal. 


La prueba del camino básico es una técnica de prueba 
de caja blanca propuesta inicialmente por Tom McCa- 
be [MCC76]. El método del camino básico permite al 
diseñador de casos de prueba obtener una medida de la 
complejidad lógica de un diseño procedimental y usar 
esa medida como guía para la definición de un conjun- 
to básico de caminos de ejecución. Los casos de prue- 
ba obtenidos del conjunto básico garantizanque durante 
la prueba se ejecuta por lo menos una vez cada senten- 
cia del programa. 


Construcciones estructuralesen forma de grafo de flujo: 


Según-sea 
. e . (Case) 
Secuencia  Si-si-no Mientras Repetir-hasta- que e 
: (14) (While) (Until) 


Q 
Fo o yo E 


Donde cada círculo representa una o más sentencias, sin bifurcaciones, 
en LDP o código fuente 


FIGURA 17.1. Notación de grafo de flujo. 
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17.41. Notación de grafo de flujo 


Antes de considerar el método del camino básico se 
debe introducir una sencilla notación para la represen- 
tación del flujo de control, denominada grafo de flujo 
(o grafo del programa)”. El grafo de flujo representael 
flujo de control lógico mediante la notación ilustrada en 
la Figura 17.1. Cada construcción estructurada (Capí- 


tulo 16) tiene su correspondiente símbolo en el grafo 
del flujo. 


Cono) 


Dibujo un yrofo de flujo cuando lo lógica de lo estructura 
de control de un módulo seo complejo. El grafo de flujo te 
permite trazor más fácilmente los cominos del programa. 


Para ilustrar el uso de un grafo de flujo, considere- 
mos la representación del diseño procedimental en la 
Figura 17.2a. En ella, se usa un diagrama de flujo para 


3 Realmente, el método del camino básico se puede llevar a cabo sin 
usar grafos de flujo. Sin embargo, sirve como herramienta Útil para 
ilustrar el método. 
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representar la estructura de control del programa. En la 
Figura 17,2b se muestra el grafo de flujo correspon- 
diente al diagrama de flujo (suponiendoque no hay con- 
diciones compuestas en los rombos de decisión del 
diagrama de flujo). 

En la Figura 17.2b, cada círculo, denominado nodo 
del grafo de flujo, representa una o más sentencias pro- 
cedimentales. Un solo nodo puede corresponder a una 
secuencia de cuadros de proceso y a un rombo de deci- 
sión. Las flechas del grafo de flujo, denominadas aris- 
tas o enlaces, representan flujo de control y son 
análogas a las flechas del diagrama de flujo. Una aris- 
ta debe terminar en un nodo, incluso aunque el nodo 
no represente ninguna sentencia procedimental (por 
ejemplo, véase el símbolo para la construcción 
Si-entonces—si—no). Las áreas delimitadas por aristas 
y nodos se denominan regiones. Cuando contabiliza- 
mos las regiones incluimos el área exterior del grafo, 
contando como otra región más”. 


a) Diagrama de flujo 


b) Grafo de flujo 


FIGURA 17.2. 


4 En la Sección 17.6.1 viene Un estudio mas detallado de los grafos 
y su empleo en las pruebas. 
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Cuando en un diseño procedimental se encuentran 
condiciones compuestas, la generación del grafo de flu- 
jo se hace un poco más complicada. Una condición com- 
puesta se da cuando aparecen uno o más operadores 
(OR, AND, NAND, NOR lógicos) en una sentenciacon- 
dicional. En la Figura 17.3 el segmento en LDP se tra- 
duce en el grafo de flujo anexo. Se crea un nodo aparte 
por cada una de las condiciones a y b de la sentencia SI 
a O b. Cada nodo que contiene una condición se deno- 
mina nodo predicado y está caracterizado porque dos o 
más aristas emergen de él. 


Nodo 


A 
IFa OR b 


Then Drocedimiento x 
Else procedimiento y 
ENDIF 


FIGURA 17.3. Lógica compuesta. 


17.42. Complejidad ciclomática 


La complejidad ciclomática es una métrica del softwa- 
re que proporcionauna medición cuantitativade la com- 
plejidad lógica de un programa. Cuando se usa en el 
contexto del método de prueba del camino básico, el 
valor calculado como complejidad ciclomática define 
el número de caminos independientes del conjunto bási- 
co de un programa y nos da un límite superior para el 
número de pruebas que se deben realizar para asegurar 
que se ejecuta cada sentencia al menos una vez. 

Un camino independiente es cualquier camino del 
programa que introduce, por lo menos, un nuevo con- 
junto de sentencias de proceso o una nueva condición. 
En términos del grafo de flujo, un camino independiente 
está constituido por lo menos por una arista que no haya 
sido recorrida anteriormente a la definición del camino. 
Por ejemplo, para el grafo de flujo de la Figura 17.2b, 
un conjunto de caminos independientes sería: 


camino 1: 1-11 

camino 2: 1-2-3-4-5-10-1-11 
camino 3: 1-2-3-6-8-9-10-1-11 
camino 4: 1-2-3-6-7-9-10-1-11 


Fíjese que cada nuevo camino introduce una nueva 
arista. El camino 


1-2-3-4-5-10-1-2-3-6-8-9-10-1-11 
no se considera un camino independiente, ya que es sim- 


plemente una combinación de caminos ya especifica- 
dos y no recorre ninguna nueva arista. 
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MON 


La complejidad ciclomática es una métrica útil para 
predecir las módulos que san más propensas a error. 
Puede ser usadatanto para planificar pruebas cama 
para diseñar casas de prueba. 


Los caminos 1,2, 3 y 4 definidos anteriormente com- 
ponen un conjunto básico para el grafo de flujo de la 
Figura 17,2b. Es decir, si se pueden diseñar pruebas que 
fuercen la ejecución de esos caminos (un conjunto bási- 
co), se garantizará que se habrá ejecutado al menos una 
vez cada sentencia del programa y que cada condición 
se habrá ejecutado en sus vertientes verdadera y falsa. 

Se debe hacer hincapié en que el conjunto básico 
no es Único. De hecho, de un mismo diseño procedi- 
mental se pueden obtener varios conjuntos básicos 
diferentes. 


¿9). ¿Cómo se cálcula 
8 la complejidad titlomátita? 


¿Cómo sabemos cuántos caminos hemos de buscar? 
El cálculo de la complejidad ciclomática nos da la res- 
puesta. La complejidad ciclomática está basada en la 
teoría de grafos y nos da una métrica del software extre- 
madamente Útil. La complejidad se puede calcular de 
tres formas: 


. 1, El número de regiones del grafo de flujo coincide 


con la complejidad ciclomática. 


La complejidad ciclomática, V(G), de un grafo de 
flujo G se define como. 


V(GH)=A-N+2 
donde A es el número de aristas del grafo de flujo y 
N es el número de nodos del mismo. 
. La complejidad ciclomática, V(G), de un grafo de 
flujo G también se define como 
V(G)=P+ 1 
donde P es el número de nodos predicado conteni- 
dos en el grafo de flujo G. 


Ko 
E 


la complejidad ciclomática determina el número 

de casos de prueba que deben ejeatase para garantizar 
que toces las sentercas de un amparar 

han sido ejautacbs al menos una vez. 


Refiriéndonos de nuevo al grafo de flujo de la Figu- 
ra 17.2b, la complejidad ciclomática se puede calcular 
mediante cualquiera de los anteriores algoritmos: 


1. el grafo de flujo tiene cuatro regiones 
2. V(G) = 11 aristas - 9 nodos +2 =4 
3. V(G) = 3 nodos predicado + 1=4. 
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Por tanto, la complejidad ciclomática del grafo de 
flujo de la Figura 17,2b es 4. 

Es más, el valor de V(G) nos da un límite superior 
para el número de caminos independientes que compo- 
nen el conjunto básico y, consecuentemente, un valor 
límite superior para el número de pruebas que se deben 
diseñar y ejecutar para garantizar que se cubren todas 
las sentencias del programa. 


17.43. Obtención de casos de prueba 


El método de prueba de camino básico se puede apli- 
car a un diseño procedimental detallado o a un código 
fuente. En esta sección, presentaremos la prueba del 
camino básico como una serie de pasos. Usaremos el 
procedimiento media, representado en LDP en la Figu- 
ra 17.4,como ejemplo para ilustrar todos los pasos del 
método de diseño de casos de prueba. Se puede ver que 
media, aunque con un algoritmo extremadamente sim- 
ple, contiene condiciones compuestas y bucles. 


1. Usando el diseño o el código como base, dibujamos 
el correspondientegrafo de flujo. Creamos un grafo 
usando los símbolos y las normas de construcción pre- 
sentadas en la Sección 16.4.1. Refiriéndonos al LDP 
de media de la Figura 17.4, se crea un grafo de flujo 
numerando las sentencias de LDP que aparecerán en 
los correspondientes nodos del grafo de flujo. El corres- 
pondiente grafo de flujo aparece en la Figura 17.5. 


PROCEDURE media; 

* Este procedimiento calcula la media de 100 o menos 
números que se encuentren entre unos limites; 
también calcula el total de entradas y el total 
de números válidos. 


INFERFACE RETURNS media, total. entrada, total. válido; 
INTERFACEACEPTS valor, mínimo, máximo; 


TYPE valor [1:100] IS SCALAR ARRAY; 

TYPE media, total. entrada, total. válido; 
Mínimo, máximo, sumalS SCALAR: 
PE ¡IS INTEGER; 

i= 1; 


total, entrada =total, válido = 0; 

suma =0; ell 

DO WHILE VALOR [il <> -999 and total entrada< 100 3 
4 ——=Incrementar total entrada en 1; 


IF valor [i] >= mínimo AND valor [i] < =maximo 6 
BE THEN incrementar total.válido en 1; 
7 


2 


suma = suma +valor [il; 
ELSE ignorar 
ENDIF 
Incrementar ¡en 1; 
9 ENODO 
If total valido>0 10: 
THEN media = suma/total valido, 
12——>ELSE media = -999, 
13ENDIF 
END media 


FIGURA 17.4. LDP para diseño de pruebas con nodos 
no identificados. 
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2. Determinamos la complejidad ciclomática del 
grafo de flujo resultante. La complejidad ciclomá- 
tica, V(G), se determina aplicando uno de los algo- 
ritmos descritos en la Sección 17.5.2.. Se debe tener 
en cuenta que se puede determinar V(G) sin desa- 
rrollar el grafo de flujo, contando todas las senten- 
cias condicionales del LDP (para el procedimiento 
media las condiciones compuestas cuentan como 2) 
y añadiendo 1. 

En la Figura 17.5, 


V(G) = 6 regiones 
V(G) = 17 aristas — 13nodos +2 =6 
V(G) =5 nodos predicado + 1=6 


FIGURA 17.5. Gratfo de flujo del procedimiento media. 


3, Determinamos un conjunto básico de caminos 
linealmente independientes. El valor de V(G) nos 
da el número de caminos linealmente independien- 
tes de la estructura de control del programa. En el 
caso del procedimiento media, hay que especificar 
seis caminos: 


1-2-10-11-13 
1-2-10-12-13 
1-2-3-10-11-13 
1-2-3-4-5-8-9-2.... 
1-2-3-4-5-6-8-9-2.... 
1-2-3-4-5-6-7-8-9-22 u.. 


Los puntos suspensivos (...) que siguen a los 
caminos 4, 5 y 6 indican que cualquier camino del 
resto de la estructura de control es aceptable. Nor- 


camino 1: 
camino 2: 
camino 3: 
camino 4: 
camino 5: 


camino 6: 
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malmente merece la pena identificar los nodos pre- 
dicado para que sea más fácil obtener los casos de 
prueba. En este caso, los nodos 2, 3, 5,6 y 10son 
nodos predicado. 


. Preparamos los casos de prueba que forzarán la 
ejecución de cada camino del conjunto básico. 
Debemos escoger los datos de forma que las condi- 
ciones de los nodos predicado estén adecuadamente 
establecidas, con el fin de comprobar cada camino. 
Los casos de prueba que satisfacenel conjunto básico 
previamente descrito son: 


Caso de prueba del camino 1: 
valor (k) = entrada válida, donde k < i definida a con- 
tinuación 
valor (i) =-999, donde 2 <= i<= 100 
resultados esperados: media correcta sobre los k 
valores y totales adecuados. 
Nota: el camino 1no se puede probar por sí solo; 


debe ser probado como parte de las pruebas de los 
caminos 4, 5 y 6. 


del softwore subestiman bastante 
pruebas necesarias para verificar * 


Caso de prueba del camino 2: 
valor (1) =-999 
resultados esperados: media = —999; otros totales 
con sus valores iniciales 
Caso de prueba del camino 3: 
intento de procesar 101 o más valores 
los primeros 100 valores deben ser válidos 
resultados esperados: igual que en el caso 
de prueba 1 
Caso de prueba del camino 4: 
valor (i) =entrada válida donde i< 100 
valor (k)< mínimo, para k < i 
resultados esperados: media correcta sobre los k 
valores y totales adecuados 
Caso de prueba del camino 5: 
valor (i) =entrada válida donde i< 100 
valor (k)> máximo, para k <= i 
resultados esperados: media correcta sobre los r 
valores y totales adecuados 
Caso de prueba del camino 6: 
valor (i) =entrada válida donde i< 100 


resultados esperados: media correcta sobre los n 
valores y totales adecuados 
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Ejecutamos cada caso de prueba y comparamos 
los resultados obtenidos con los esperados. Una vez 
terminados todos los casos de prueba, el responsable 
de la prueba podrá estar seguro de que todas las sen- 
tencias del programa se han ejecutado por lo menos 
una vez. 

Es importante darse cuenta de que algunos cami- 
nos independientes (por ejemplo, el camino 1 de 
nuestro ejemplo) no se pueden probar de forma ais- 
lada. Es decir, la combinación de datos requerida 
para recorrer el camino no se puede conseguir con 
el flujo normal del programa. En tales casos, estos 
caminos se han de probar como parte de otra prue- 
ba de camino. 


17,44. Matrices de grafos 


El procedimiento para obtener el grafo de flujo, e 
incluso la determinación de un conjunto de caminos 
básicos, es susceptible de ser mecanizado. Para desa- 
rrollar una herramienta software que ayude en la prue- 
ba del camino básico, puede ser bastante Útil una 
estructura de datos denominada matriz de grafo. 

Una matriz de grafo es una matriz cuadrada cuyo 
tamaño (es decir, el número de filas y de columnas) 
es igual al número de nodos del grafo de flujo. Cada 
fila y cada columna corresponde a un nodo específi- 
co y las entradas de la matriz corresponden a las cone- 
xiones (aristas) entre los nodos. En la Figura 17.6 se 
muestra un sencillo ejemplo de un grafo de flujo con 
su correspondiente matriz de grafo [BEI9O]. 

. En la figura, cada nodo del grafo de flujo está iden- 
tificado pór un número, mientras que cáda arista lo 
está por su letra. Se sitúa una entrada en la matriz por 
cada conexión entre dos nodos. Por ejemplo, el nodo 
3 está conectado con el nodo 4 por la arista b. 


> ¿Qué es una matriz 
de grafos y cómo aplicarla 


en la prueba? 


Hasta aquí, la matriz de grafo no es nada más que una 
'representación tabular del grafo de flujo. Sin embargo, 
añadiendoun peso de enlace a cada entrada de la matriz, 
la matriz de grafo se puede convertiren una potente herra- 
mienta para la evaluación de la estructura de control del 
programa durante la prueba. El peso de enlace nos da 
información adicional sobre el flujo de control. En su for- 
ma más Sencilla,el peso de enlace es 1 (existeuna cone- 
xión) Ó O (no existe conexión). A los pesos de enlace se 
les puede asignar otras propiedades más interesantes: 
+ laprobabilidad de que un enlace (arista) seaejecutado; 
+ el tiempo de procesamiento asociado al recorrido de 

un enlace; 
+. la memoria requerida durante el recorrido de un 

enlace; y 


+ los recursos requeridos durante el recorrido de un 
enlace. 


Para ilustrarlo, usaremos la forma más simple de 
peso, que indica la existencia de conexiones (06 1).La 
matriz de grafo de la Figura 17.6 se rehace tal y como 
se muestra en la Figura 17.7. Se ha reemplazado cada 
letra por un 1, indicando la existencia de una conexión 
(se han excluido los ceros por claridad). Cuando se 
representa de esta forma, la matriz se denomina matriz 
de conexiones. . 


Conectado 
al hodo 


Nod8 


Grafo de flujo 


Matriz del grafo 


FIGURA 17.6. Matriz del grafo. 


En la Figura 17.7, cada fila con dos o más entra- 
das representa un nodo predicado. Por tanto, los 
cálculos aritméticos que se muestran a la derecha de 
la matriz de conexiones nos dan otro nuevo método 
de determinación de la complejidad ciclomática (Sec- 
ción 17.4.2). 

Beizer [BEI90] proporciona un tratamiento profun- 
do de otros algoritmos matemáticos que se pueden apli- 
car alas matrices de grafos. Mediante estas técnicas, el 
análisis requerido para el diseño de casos de prueba se 
puede automatizar parcial o totalmente. 


Conectado 
al nodo 


Nodo . E . sa E Conexiones 


1 1-1=0 
2 
3 2-1= 
4 2-1= 
5 2-1= 
3+1=4 
Matriz de grafo 
Complejidad 
ciclomática 


FIGURA 17.7. Matriz de conexiones. 
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La técnica de prueba del camino básico descrita en la 
Sección 17.4es una de las muchas técnicas para la prue- 
ba de la estructura de control. Aunque la prueba del 
camino básico es sencilla y altamente efectiva, no es 
suficiente por sí sola. En esta sección se tratan otras 
variantes de la prueba de estructura de control. Estas 
variantes amplían la cobertura de la prueba y mejoran 
la calidad de la prueba de caja blanca. 


17.5.1. Prueba de condición” 


US] 
SS 


CLAVE 


los errores son mucho más comunes en el entorno 
de los condicioneslógicas que en los sentencias de 
proceso secuencial. 


La prueba de condición es un método de diseño de 
casos de prueba que ejercita las condiciones lógicas 
contenidas en el módulo de un programa. Una condi- 
ción simple es una variable lógica o una expresión 
relacional, posiblemente precedida con un operador 
NOT («»). Una expresión relacional toma la siguien- 
te forma 


E, < operador-relacional> E, 


donde E, y E, son expresiones aritméticas y <opera- 
dor-relacional> puede ser alguno de los siguientes: «<», 
«<=», «=», «2» («=» desigualdad), «>», O «>=», Una 
condición compuesta está formada por dos O más con- 
diciones simples, operadoreslógicos y paréntesis. Supo- 
nemos que los operadores lógicos permitidos en una 
condición compuesta incluyen OR («l»), AND («8%») y 
NOT («-»). A una condición sin expresiones relacio- 
nales se la denomina Expresión lógica. 

Por tanto, los tipos posibles de componentes en una 
condición pueden ser: un operador lógico, una variable 
lógica, un par de paréntesis lógicos (que rodean a una 
condición simple o compuesta), un operador relacional 
o una expresión aritmética. 

Si una condición es incorrecta, entonces es inco- 
rrecto al menos un componente de la condición. Así, 
los tipos de errores de una condición pueden ser los 
siguientes: 

+ error en operador lógico (existencia de operadores 
lógicos incorrectos/desaparecidos/sobrantes) 

error en variable lógica 

error en paréntesis lógico 

error en operador relacional 


error en expresión aritmética. 


SLas secciones 17.5.1. y 17.5.2. se han adaptado de [TAI89] con per- 
miso del profesor K.C. Tai. 


El método de laprueba de condiciones se centra en la 
prueba de cada una de las condiciones del programa. Las 
estrategias de prueba de condiciones (tratadas posterior- 
mente en este capítulo) tienen, generalmente, dos venta- 
jas. La primera, que la cobertura de la prueba de una 
condición es sencilla. La segunda, que la cobertura de la 
prueba de las condiciones de un programa da una orien- 
tación para generar pruebas adicionales del programa. 

El propósito de la prueba de condiciones es detectar, 
no sólo los errores en las condiciones de un programa, 
sino también otros errores en dicho programa. Siun con- 
junto de pruebas de un programa P es efectivo para 
detectar errores en las condiciones que se encuentran 
en P, es probable que el conjunto de pruebas también sea 
efectivo para detectar otros errores en el programa P. 
Además, si una estrategia de prueba es efectiva para 
detectar errores en una condición, entonces es probable 
que dicha estrategia también sea efectiva para detectar 
errores en el programa. 

Se han propuesto una serie de estrategias de prueba 
de condiciones. La prueba de ramificaciones es, posi: 
blemente, la estrategia de prueba de condiciones más 
sencilla. Para una condición compuesta C, es necesario 
ejecutar al menos una vez las ramas verdadera y falsa 
de C y cada condición simple de C [MYE79]. 


Cons: 


Codo vez que decides efectuar una prueba de condición, 
deberás evaluar cada condición en un intento 

por descubrirerrores. ¡Este es un escondrijo ideal 

pora los errores! 


La prueba del dominio [WHI80] requiere la realiza- 
ción de tres o cuatro pruebas para una expresión rela- 
cional. Para una expresión relacional de la forma 


E, <operador-relaciona¡> E, 


se requieren tres pruebas, para comprobar que el valor 
de E, es mayor, igual o menor que el valor de E,, res- 
pectivamente [HOW82]. Si el <operador-relacional> 
es incorrecto y E, y E, son correctos, entonces estas tres 
pruebas garantizan la detección de un error del opera- 


dor relacional. Para detectar errores en E, y E,, la prue- 
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ba que haga el valor de £, mayor O menor que el de E, 
debe hacer que la diferencia entre estos dos valores sea 
lo más pequeña posible. 

Para una expresión lógica con » variables, habrá que 
realizar las 2”pruebas posibles (n> 0). Esta estrategia 
puede detectar errores de un operador, de una variable 
y de un paréntesis lógico, pero sólo es práctica cuando 
el valor de n es pequeño. 


www.elsolucionario.net 


INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRACTICO 


También se pueden obtener pruebas sensibles a error 
para expresiones lógicas [FOS84, TAI87]. Para una 
expresión lógica singular (una expresión lógica en la 
cual cada variable lógica sólo aparece una vez) con n 
variables lógicas (n> 0), podemos generar fácilmente 
un conjunto de pruebas con menos de 2” pruebas, de tal 
forma que ese grupo de pruebas garantice la detección 
de múltiples errores de operadores lógicos y también 
sea efectivo para detectar otros errores. 

Tai [TAI89] sugiere una estrategia de prueba de 
condiciones que se basa en las técnicas destacadas 
anteriormente. La técnica, denominada BRO* (prue- 
ba del operador relacional y de ramificación), garan- 
tiza la detección de errores de operadores relacionales 
y de ramificaciones en una condición dada, en la que 
todas las variables lógicas y operadores relacionales 
de la condición aparecen sólo una vez y no tienen 
variables en común. 

La estrategia BRO utiliza restricciones de condición 
para una condición C, Una restricción de condición para 
C con n condiciones simples se define como (D,, 
D,,....D,), donde D, (0 <¡ < n) es un símbolo que espe- 
cifica una restricción sobre el resultado de la i-ésima 
condición simple de la condición C, Una restricción de 
condición D para una condición C se cubre o se trata en 
una ejecución de C, si durante esta ejecución de C, el 
resultado de cada condición simple de C satisface la res- 
tricción correspondiente de D, 

Para una variable lógica B, especificamos una res- 
tricción sobre el resultado de B, que consiste en que B 
tiene que ser verdadero (v) o falso (f). De forma simi- 
lar, para una expresión relacional, se utilizan los sím- 
bolos >, = y < para especificar restricciones sobre el 
resultado de la expresión. 

Como ejemplo, consideremos la condición 


Es B, « B, 


donde B, y B, son variables lógicas. La restricción de 
condición para C, es de la forma (D,, D,), donde D, y 
D, son «v» O «f», El valor (v, f) es una restricción de 
condición para C, y se cubre mediante la prueba que 
hace que el valor de B, sea verdadero y el valor de B, 
sea falso. La estrategia de prueba BRO requiere que el 
conjunto de restricciones [(v, v), (£, v), (v, f)) sea 
cubierto mediante las ejecuciones de C,. Si C, es inco- 
rrecta por uno o más errores de operador lógico, por lo 
menos un par del conjunto de restricciones forzará el 
fallo de C.,. 

Como segundo ejemplo, consideremos una condi- 
ción de la forma 


C;,: B, £ (E, = E,) 
donde B, es una expresión lógica y E, y E, son expre- 
siones aritméticas. Una restricción de condición para C, 
es de la forma (D,, D,), donde D, es «v» o «f» y D, es 
>, =0<, Puesto que C, es igual que C,, excepto en que 
la segunda condición simple de C, es una expresión rela- 


* En ingles, Branch arid Relational Operator 
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cional, podemos construir un conjunto de restricciones 
para C, mediante la modificación del conjunto de res- 
tricciones ( (v, v), (£, v), (v, £)) definido para C,. Obsér- 
vese que «v» para (E, = E,) implica «=» y que «f» para 
(E, = E,) implica «< »o «>». Al reemplazar (v, v) y (f, 
v) por (v, =) y (f, =), respectivamente y reemplazando 
(v, £) por (v, <) y (v,>), el conjunto de restricciones resul- 
tante para C, es [(v, =), (f,=), (v, <), (v, >)).La cobertura 
del conjunto de restricciones anterior garantizará la detec- 
ción de errores del operadorrelacional o lógico en C,. 

Como tercer ejemplo, consideremos una condición 
de la forma 


Ez (E,>E)4€(E3 = E) 
donde E,, E», E, y E, son expresiones aritméticas. Una 
restricción de condición para C, es de la forma (D,, 
D,), donde todos los D, y D, son >, =0<, Puesto que 
C,es igual que C, excepto en que la primera condi- 
ción simple de C, es una expresión relacional, pode- 
mos construir un conjunto de restricciones para C, 


mediante la modificación del conjunto de restriccio- 
nes para C,, obteniendo 


(O, =), E, =), (<, =), O, >), (>. <)) 


La cobertura de este conjunto de restricciones garan- 
tizará la detección de errores de operador relacional 
en C,. 


17.5.2, Prueba del £lujo de datos 


El método de prueba de flujo de datos selecciona cami- 
nos de prueba de un programa de acuerdo con la ubi- 
cación de las definiciones y los usos de las variables del 
programa. Se han estudiado y comparado varias estra- 
tegias de prueba de flujo de datos (por ejemplo, 
[FRA88], [NTA88], [FRA93]). 

Para ilustrar el enfoque de prueba de flujo de datos, 
supongamos que a cada sentencia de un programa se le 
asigna un número único de sentencia y que las funcio- 
nes no modifican sus parámetros oO las variables globa- 
les. Para una sentenciacon S como número de sentencia, 


DEF(S) =(X | la sentencia S contiene una definición 
deX ] 


USO(S) =[X | la sentencia S contiene un uso de X] 


Si la sentencia S es una sentencia ¡fo de bucle, su con- 
junto DEF estará vacío y su conjunto USE estará basa- 
do en la condición de la sentencias, La definición de una 
variableX en una sentencias se dice que está viva en una 
sentenciaS' si existe un camino de la sentencias a la sen- 
tencia S' que no contenga otra definición de X. 


Cons) 


Es para realista asumir que la prueba del flujo de datas 
puede ser usada ampliamente cuando probamos grandes 
sistemas. En cualquier rasa, puede ser utilizada en areas 
del software que sean sospechosos. 
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Una cadena de definición-uso (ocadena DU) de una 
variable X tiene la forma [X, $, S”], donde $ y S” son 
números de sentencia, X está en DEF(S) y en USO(S”) 
y la definición de X en la sentenciaS está viva en la sen- 
tencia S”. 

Una sencilla estrategia de prueba de flujo de datos 
se basa en requerir que se cubra al menos una vez cada 
cadena DU. Esta estrategia se conoce como estrategia 
deprueba DU. Se ha demostrado que la prueba DU no 
garantiza que se cubran todas las ramificaciones de un 
programa. Sin embargo, solamente no se garantiza el 
cubrimiento de una ramificación en situaciones raras 
como las construcciones ¡fethen-else en las que la par- 
te then no tiene ninguna definición de variable y no exis- 
te la parte else. En esta situación, la prueba DU no cubre 
necesariamente la rama else de la sentencia $superior. 

Las estrategias de prueba de flujo de datos son Úti- 
les para seleccionarcaminos de prueba de un programa 
que contenga sentencias if o de bucles anidados. Para 
ilustrar esto, consideremos la aplicación de la prueba 
DU para seleccionar caminos de prueba para el LDP 


que sigue: 
proc Xx 
Bl: 
do while C1 
1f C2 
then 
¿Ef CA 
then B4; 
else B5; 
endif; 
else 
TÉ CS 
then b2; 
else B3 ; 
endif; 
endif; 
enddo; 
BÓ6; 
end proc; 


Para aplicar la estrategia de prueba DU para seleccio- 
nar caminos de prueba del diagrama de flujo de control, 
necesitamos conocer las definiciones y los usos de las 
variables de cada condición o cada bloque del LDP. Asu- 
mimos que la variable X es definida en la Última sen- 
tencia de los bloques B1, B2, B3, B4 y BS, y que se usa 
en la primera sentencia de los bloques B2, B3, B4, B5 
y B6. La estrategia de prueba DU requiere una ejecu- 
ción del camino más corto de cada B¡,0<i< 5, a cada 
B., 1<¡<6. (Tal prueba también cubre cualquier uso de 
la variable X en las condiciones C1, C2, C3 y C4). Aun- 
que hay veinticinco cadenas DU de la variable X, sólo 
necesitamos cinco caminos para cubrir la cadena DU. 
La razón es que se necesitan cinco caminos para cubrir 
la cadena DU de X desde B,, 0< 15 5, hasta B6, y las 


---NICAS DE PRUEBA DEL SOFTWARE 


otras cadenas DU se pueden cubrir haciendo que esos 
cinco caminos contengan iteraciones del bucle. 

Dado que las sentencias de un programa están rela- 
cionadas entre sí de acuerdo con las definiciones de las 
variables, el enfoque de prueba de flujo de datos es efec- 
tivo para la protección contra errores. Sin embargo, los 
problemas de medida de la cobertura de la prueba y de 
selección de caminos de prueba para la prueba de flujo 
de datos son más difíciles que los correspondientes pro- 
blemas para la prueba de condiciones. 


17.5.3. Prueba de bucles 


Los bucles son la piedra angular de la inmensa mayo- 
ría de los algoritmos implementados en software. Y sin 
embargo, les prestamos normalmente poca atención 
cuando llevamos a cabo las pruebas del software. 


Consuof) 


Las estructuras de bucles complejos esotro lugar 
propenso a errores. Por tonto, es muy valiosorealizar 
diseños depruebas que ejercitencompletamente 

los estructuras bucle. 


La prueba de bucles es una técnica de prueba de caja 
blanca que se centra exclusivamenteen la validez de las 
construcciones de bucles. Se pueden definir cuatro cla- 
ses diferentes de bucles [BE190]: bucles simples, bucles 
concatenados, bucles anidados y bucles no estructura- 
dós (Fig. 17.8). 


Bucles simples.A los bucles simples seles debe apli- 
car el siguiente conjunto de pruebas, donde n es el 
número máximo de pasos permitidos por el bucle: 


1. pasar por alto totalmente el bucle 

2. pasar una sola vez por el bucle 

3. pasar dos veces por el bucle 

4. hacer m pasos por el bucle con m <n 
5. hacer n —1,n y n+l pasos por el bucle 


Bucles 
anidados 


Bucles 
simples 


Bucles 
concatenados 


Bucles no 
estructurados 


FIGURA 17.8. Clases de bucles. 
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Bucles anidados. Si extendiéramosel enfoquede prue- 
ba de los bucles simples a los bucles anidados, el número 
de posibles pruebas aumentaría geométricamente a medi- 
da que aumenta el nivel de anidamiento. Esto llevaría a 
un número impracticablede pruebas. Beizer [BEI90] sugie- 
re un enfoque que ayuda a reducir el número de pruebas: 


1. Comenzar por el bucle más interior. Establecer o con- 
figurar los demás bucles con sus valores mínimos. 


2. Llevar a cabo las pruebas de bucles simples para el 
bucle más interior, mientras se mantienen los paráme- 
tros de iteración (por ejemplo, contador del bucle) de 
los bucles externos en sus valores mínimos. Añadir 
otras pruebas para valores fuera de rango o excluidos. 


pd 


Progresar hacia fuera, llevando a cabo pruebas para 
el siguiente bucle, pero manteniendotodos los bucles 
externos en sus valores mínimos y los demás bucles 
anidados en sus valores «típicos». 


4. Continuar hasta que sehayan probadotodos los bucles. 


Bucles concatenados.Los bucles concatenados se 
pueden probar mediante el enfoque anteriormente defi- 
nido para los bucles simples, mientras cada uno de los 
bucles sea independiente del resto. Sin embargo, si 
hay dos bucles concatenados y se usa el controlador 
del bucle 1 como valor inicial del bucle 2, entonces 
los bucles no son independientes. Cuando los bucles 
no son independientes, se recomienda usar el enfoque 
aplicado para los bucles anidados. 


Consuof) 


No debes probar los bucles no estructurados. Rediséñalos. 


Bucles no estructurados. Siempre que sea posi- 
ble, esta clase de bucles se deben rediseñar para que 
se ajusten a las construcciones de programación 
estructurada (Capítulo 16). 


Las pruebas de caja negra, también denominada prue- 
ba de comportamiento, se centran en los requisitos fun- 
cionales del software. O sea, la prueba de caja negra 
permite al ingeniero del software obtener conjuntos de 
condiciones de entrada que ejerciten completamente 
todos los requisitos funcionales de un programa. La 
prueba de caja negra no es una alternativa a las técni- 
cas de prueba de caja blanca. Más bien se trata de un 
enfoque complementario que intenta descubrir diferen- 
tes tipos de errores que los métodos de caja blanca. 

La prueba de caja negra intenta encontrar errores de 
las siguientes categorías: (1) funciones incorrectas O 
ausentes, (2) errores de interfaz, (3) errores en estruc- 
turas de datos o en accesos a bases de datos externas, 

(4) errores de rendimiento y (5 )errores de inicializa- 
ción y de terminación. 

A diferencia de la prueba de caja blanca, que se lle- 
va a cabo previamente en el proceso de prueba, la prue- 
ba de caja negra tiende a aplicarse durante fases 
posteriores de la prueba (véase el Capítulo 18). Ya que 
la prueba de caja negra ignora intencionadamente la 
estructura de control, centra su atención en el campo de 
la información. Las pruebas se diseñan para responder 
a las siguientes preguntas: 


+. ¿Cómo se prueba la validez funcional? 
+ ¿Cómo se prueba el rendimiento y el comportamiento 
del sistema? 


+. ¿Qué clases de entrada compondrán unos buenos 
casos de prueba? 


+ ¿Esel sistemaparticularmente sensiblea ciertos valo- 
res de entrada? 


+. ¿De qué forma están aislados los límites de una clase 
de datos? 


*« ¿Qué volúmenes y niveles de datos tolerará el sis- 
tema? 


- ¿Qué efectos sobre la operación del sistema tendrán 
combinaciones específicas de datos? 


Mediante las técnicas de prueba de caja negra se 
obtiene un conjunto de casos de prueba que satisfa- 
cen los siguientes criterios [MYE79]: (1) casos de 
prueba que reducen, en un coeficiente que es mayor 
que uno, el número de casos de prueba adicionales 
que se deben diseñar para alcanzar una prueba razo- 
nable y (2)casos de prueba que nos dicen algo sobre 
la presencia O ausencia de clases de errores en lugar 
de errores asociados solamente con la prueba que esta- 
mos realizando. 


17.6.1. Métodos de prueba basados en grafos 


El primer paso en la prueba de caja negra es entender 
los objetos” que se modelan en el software y las rela- 
ciones que conectan a estos objetos. Una vez que se ha 
llevado a cabo esto, el siguiente paso es definir una serie 
de pruebas que verifiquen que «todos los objetos tienen 
entre ellos las relaciones esperadas» [BE195]. Dicho de 
otra manera, la prueba del software empieza creandoun 
grafo de objetos importantes y sus relaciones, y después 


$En este contexto, el término «objeto» comprende los objetos de datos 
que se estudiaron en los Capítulos 11 y 12 así como objetos de pro- 
grama tales como módulos o colecciones de sentencias del lenguaje 
de programación. 
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diseñando una serie de pruebas que cubran el grafo de 
manera que se ejerciten todos los objetos y sus relacio- 
nes para descubrir los errores. 


pa 


Un grafo representa la relación entre objeto dato y objeto 
programa, permitiéndonos derivar casos de prueba 
que buscan errores asociados con estas relaciones. 


Enlace dirigido 


Objeto 
(peso de enlace) 


Peso del nodc 


dirigido | 
AE Obieto Enlaces paralelos (valgr] 
3 
a) Notación de grato 


La selección del menú 
(tiempo de generación < 1.0 seg.) 
Permite 
la edición de 


Atributos: 
Dimensiones de inicio 
configuración 

O preferencias 
predeterminadas 
Color de fondo: blanco 
Color del texto: 

color o preferencias 
predeterminadas 


Se representa como Contisñó 


b) Un sencillo ejemplo 


RGURA 17.9. 


Para llevar a cabo estos pasos, el ingeniero del soft- 
ware empieza creando un grafo —uma colección de nodos 
que representan objetos; enlaces que representan las rela- 
cionesentre los objetos;pesos de nodos que describen las 
propiedades de un nodo (por ejemplo, un valor específi- 
code datos o comportamiento de estado) y pesos de enla- 
ces que describen alguna característica de un enlace—. 

En la Figura 17.9a se muestra una representación 
simbólica de un grafo. Los nodos se representan como 
círculos conectados por enlaces que toman diferentes for- 
mas. Un enlace dirigido (representado por una flecha) 
indica que una relación se mueve sólo en una dirección. 
Ur enlace bidireccional, también denominado enlace 
simétrico, implica que la relación se aplicaen ambos sen- 
tidos. Los enlaces paralelos se usan cuando se establecen 
diferentesrelaciones entre los nodos del grafo. 

Como ejemplo sencillo, consideremos una parte de 
un grafo de una aplicación de un procesador de texto 
(Fig. 17.9b) donde: 


objeton.? 1 = selección en el menú de archivo nuevo 
objeto n.* 2 = ventana del documento 
objeto n.* 3 = texto del documento 


Si losconceptos anteriores suenan vagamente familiares, recordemos 
que los grafos se usaron también en la Sección 17.4.1 para crear un 
grafo del programa para el método de la prueba del camino básico. Los 
nodos del grafo del programa contenían instrucciones (objetosde pro- 
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AP 


Como se muestra en la figura, una selección del 
menú en archivo nuevo genera una ventana del docu- 
mento. El peso del nodo de ventana del documento 
proporciona una lista de los atributos de la ventana que 
se esperan cuando se genera una ventana. El peso del 
enlace indica que la ventana se tiene que generar en 
menos de 1.0 segundos. Un enlace no dirigido esta- 
blece una relación simétrica entre selección en el menú 
de archivo nuevo y texto del documento, y los enla- 
ces paralelos indican las relaciones entre la ventana 
del documento y el texto del documento. En reali- 
dad, se debería generar un grafo bastante más detalla- 
do como precursor al diseño de casos de prueba. El 
ingeniero del software obtiene entonces casos de prue- 
ba atravesando el grafo y cubriendo cada una de las 
relaciones mostradas. Estos casos de prueba están dise- 
ñados para intentar encontrar errores en alguna de las 
relaciones. 

Beizer [BE195] describe un número de métodos de 
prueba de comportamiento que pueden hacer uso de los 
grafos: 


Modelado del flujo de transacción. Los nodos 
representan los pasos de alguna transacción (por 
ejemplo, los pasos necesarios para una reserva en una 
línea aérea usando un servicio en línea), y los enla- 
cesrepresentan las conexioneslógicas entre los pasos 
(por ejemplo, vuelo.información. entrada es seguida 
de validación!disponibilidad. procesamiento). El dia- 
grama de flujo de datos (Capítulo 12) puede usarse 
para ayudar en la creación de grafos de este tipo. 


Modelado de estadofinito. Los nodos representan 
diferentes estados del software observables por el 
usuario (por ejemplo, cada una de las «pantallas» que 
aparecen cuando un telefonista coge una petición por 
teléfono), y los enlaces representan las transiciones 
que ocurren para moverse de estado a estado (por 
ejemplo, petición-información se verifica durante 
inventario-disponibilidad-búsqueda y es seguido por 
cliente-factura-informaciónentrada). El diagrama 
estado-transición (Capítulo 12) puede usarse para 
ayudar en la creación de grafos de este tipo. 


Modelado del flujo de datos. Los nodos son 
objetos de datos y los enlaces son las transforma- 
ciones que ocurren para convertir un objeto de 
datos en otro. Por ejemplo, el nodo FICA.impues- 
to.retenido (FIR) se calcula de brutos.sueldos 
(BS) usando la relación FIR =0,62 X BS. 


Modelado de planificación. Los nodos son obje- 
tos de programa y los enlaces son las conexiones 
secuenciales entre esos objetos. Los pesos de enla- 
ce se usan para especificar los tiempos de ejecución 
requeridos al ejecutarse el programa. 


grama) caracterizados como representaciones de diseño procedimen- 
tal o como código fuente y los enlaces dirigidos indicaban el flujo de 
control entre estos objetos del programa. Aquí se extiende el uso de los 
grafos para incluirla prueba de caja negra. 
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Un estudio detallado de cada uno de estos métodos 
de prueba basados en grafos está más allá del alcance 
de este libro. El lector interesado debería consultar 
[BEI95] para ver un estudio detallado. Merece la pena, 
sin embargo, proporcionar un resumen genérico del 
enfoque de pruebas basadas en grafos. 

¿Cuáles son las actividades 


bs generales requeridas 
durante la prueba basada 
en un grafo? 


Las pruebas basadas en grafos empiezan con la defi- 
nición de todos los nodos y pesos de nodos. O sea, se 
identifican los objetos y los atributos. El modelo de datos 
(Capítulo 12) puede usarse como punto de partida, pero 
es importante tener en cuenta que muchos nodos pue- 
den ser objetos de programa (no representados explíci- 
tamente en el modelo de datos). Para proporcionar una 
indicación de los puntos de inicio y final del grafo, es 
útil definir unos nodos de entrada y salida. 

Una vez que se han identificado los nodos, se debe- 
rían establecer los enlaces y los pesos de enlaces. En 
general, conviene nombrar los enlaces, aunque los enla- 
ces que representan el flujo de control entre los objetos 
de programa no es necesario nombrarlos. 

En muchos casos, el modelo de grafo puede tener 
bucles (por ejemplo, un camino a través del grafo en el 
que se encuentran uno o más nodos más de una vez). La 
prueba de bucle (Sección 17,5.3) se puede aplicar tam- 
bién a nivel de comportamiento (de caja negra). El grafo 
ayudará a identificar aquellos bucles que hay que probar. 

Cada relación es estudiada separadamente, de mane- 
ra que se puedan obtener casos de prueba. La transiti- 
vidad de relaciones secuenciales es estudiada para 
determinar cómo se propaga el impacto de las relacio- 
nes a través de objetos definidos en el grafo. La transi- 
tividad puede ilustrarse considerando tres objetos X, Y 
y Z. Consideremos las siguientes relaciones: 


X es necesaria para calcular Y 
Y es necesaria para calcular Z 


Por tanto, se ha establecido una relación transitiva 
entre X y Z: 


X es necesaria para calcular £ 


Basándose en esta relación transitiva, las pruebas 
para encontrar errores en el cálculo de Z deben consi- 
derar una variedad de valores para X e Y. 

La simetría de una relación (enlace de grafo) es tam- 
bién una importante directrizpara diseñarcasos de prue- 
ba. Si un enlacees bidireccional (simétrico),es importante 
probar esta característica. La característica UNDO 
[BEI95] (deshacer) en muchas aplicaciones para orde- 
nadores personales implementa una limitada simetría. Es 
decir, UNDO permite deshacer una acción después de 
haberse completado. Esto debería probarse minuciosa- 
mente y todas las excepciones (por ejemplo, lugares don- 


296 


de no se puede usar UNDO deberían apuntarse. Final- 
mente, todos los nodos del grafo deberían tener una rela- 
ción que los lleve de vuelta a ellos mismos; en esencia, 
un bucle de «no acción» O «acción nula». Estas relacio- 
nes reflexivas deberían probarse también. 

Cuando empieza el diseño de casos de prueba, el pri- 
mer objetivoes conseguir la cobertura de nodo. Esto sig- 
nifica que las pruebas deberían diseñarse para demostrar 
que ningún nodo se ha omitido inadvertidamentey que 
los pesos de nodos (atributos de objetos) son correctos. 

A continuación, se trata la cobertura de enlaces. Todas 
las relaciones se prueban basándose en sus propiedades. 
Por ejemplo, una relación simétrica se prueba para 
demostrar que es, de hecho, bidireccional. Una relación 
transitiva se prueba para demostrar que existe transiti- 
vidad. Una relación reflexiva se prueba para asegurarse 
de que hay un bucle nulo presente. Cuando se han espe- 
cificado los pesos de enlace, se diseñan las pruebas para 
demostrar que estos pesos son válidos. Finalmente, se 
invocan las pruebas de bucles (Sección 17.5.3). 


17,6,2, Partición equivalente 


Lapartición equivalente es un método de prueba de caja 
negra que divide el campo de entrada de un programa 
en clases de datos de los que se pueden derivar casos 
de prueba. Un caso de prueba ideal descubre de forma 
inmediata una clase de errores (por ejemplo, proceso 
incorrecto de todos los datos de carácter) que, de otro 
modo, requerirían la ejecución de muchos casos antes 
de detectar el error genérico. La partición equivalente 
se dirige a la definición de casos de prueba que descu- 
bran clases de errores, reduciendo así el número total 
de casos de prueba que hay que desarrollar. 


Cionsuof) 


las clases de entrada san conocidas relativamente 
temprano en el procesa de software. Por esto razón, 
comenzamos pensando en la partición equivalente 
una vez el diseña ha sido creada. 


El diseño de casos de prueba para la partición equi- 
valente se basa en una evaluación de las clases de equi- 
valencia para una condición de entrada. Mediante 
conceptos introducidosen la sección anterior, si un con- 
junto de objetos puede unirse por medio de relaciones 
simétricas, transitivas y reflexivas, entonces existe una 
clase de equivalencia [BEI195]. Una clase de equivalen- 
cia representa un conjunto de estados válidos o no váli- 
dos para condiciones de entrada. Típicamente, una 
condición de entrada es un valor numérico específico,un 
rango de valores, un conjunto de valores relacionadoso 
una condición lógica. Las clases de equivalencia se pue- 
den definir de acuerdo con las siguientes directrices: 


1. Si una condición de entrada especifica un rango, 
se define una clase de equivalencia válida y dos no 
válidas. 
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2. Si una condición de entrada requiere un valor espe- 
cífico, se define una clase de equivalencia válida y 
dos no válidas. 


3. Si una condición de entrada especifica un miembro 
de un conjunto, se define una clase de equivalencia 
válida y una no válida. 


4. Si una condición de entrada es lógica, se define una 
clase de equivalencia válida y una no válida. 


Comoejemplo, consideremos los datos contenidosen 
una aplicación de automatización bancaria. El usuario 
puede «llamar» al banco usando su ordenador personal, 
dar su contraseña de seis dígitos y continuar con una serie 
de órdenes tecleadas que desencadenarán varias funcio- 
nes bancarias. El software proporcionado por la aplica- 
ción bancaria acepta datos de la siguiente forma: 


Código de área: en blanco o un número de tres dígitos 


Prefijo: número de tres dígitos que no comience por 
0o 1 


Sufijo: número de cuatro dígitos 
Contraseña: valor alfanumérico de seis dígitos 


Ordenes: «comprobar», «depositar», «pagar factu- 
ra», etc. 


Las condicionesde entrada asociadas con cada elemento 
de la aplicación bancaria se pueden especificarcomo: 


Código de área: condición de entrada, lógica—+el códi- 
go de área puede estar o no presente 
condición de entrada, rango—valo- 
res definidos entre 200 y 999, con 
excepciones específicas 


Prefijo: condición de entrada, rango — valor 
especificado > 200 sin dígitos O 

Sufijo: condición de entrada, valor — lon- 
gitud de cuatro dígitos 

Contraseña: condición de entrada, lógica — 
la palabra clave puede estar o no 
presente; 
condición de entrada, valor —cade- 
na de seis caracteres 

Orden: condición de entrada, conjunto— 


contenida en las órdenes listadas 
anteriormente 


Aplicando las directrices para la obtención de clases 
de equivalencia, se pueden desarrollar y ejecutar casos 
de prueba para cada elemento de datos del campo de 
entrada. Los casos de prueba se seleccionan de forma 
que se ejercite el mayor número de atributos de cada 
clase de equivalencia a la vez. 


17.63. Análisis de valores límite 


Por razones que no están del todo claras, los errores 
tienden a darse más en los límites del campo de entra- 
da que en el «centro». Por ello, se ha desarrollado el 
análisis de valores límites (AVL) como técnica de 
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prueba. El análisis de valores límite nos lleva a una 
elección de casos de prueba que ejerciten los valores 


límite. 
S 
$ 
ae 


AVL amplía la particiónequivalente para fijorse sobre 
datos en el «límite» de una clase de equivalencia. 


El análisis de valores límite es una técnica de dise- 
ño de casos de prueba que complementa a la partición 
equivalente. En lugar de seleccionar cualquier elemen- 
to de una clase de equivalencia, el AVE lleva a la elec- 
ción de casos de prueba en los «extremos» de la clase. 
En lugar de centrarse solamente en las condiciones de 


entrada, el AVL obtiene casos de prueba también para 
el campo de salida [MYE79]. 


Las directrices de AVL son similares en muchos 
aspectos a las que proporciona la partición equivalente: 


¿ Cómo se crean casos 
de prueba para el AVL? 


1. Siuna condición de entrada especifica un rango deli- 
mitado por los valores a y b, se deben diseñar casos 
de prueba para los valores a y b, y para los valores 
justo por debajo y justo por encima de a y b, res- 
pectivamente. 


2. Siuna condición de entrada especifica un número de 
valores, se deben desarrollar casos de prueba que 
ejerciten los valores máximo y mínimo. También se 
deben probar los valores justo por encima y justo por 
debajo del máximo y del mínimo. 


3. Aplicar las directrices 1 y 2 a las condiciones de 
salida. Por ejemplo, supongamos que serequiere una 
tabla de «temperatura / presión» como salida de un 
programa de análisis de ingeniería. Se deben dise- 
ñar casos de prueba que creen un informe de salida 
que produzca el máximo (y el mínimo) número per- 
mitido de entradas en la tabla. 


4. Si las estructuras de datos internas tienen límites 
preestablecidos (por ejemplo, una matriz que tenga 
un límite definido de 100 entradas), hay que asegu- 
rarse de diseñar un caso de prueba que ejercite la 
estructura de datos en sus límites. 


La mayoría de los ingenieros del software llevan a 
cabo de forma intuitiva alguna forma de AVL, Apli- 
cando las directricesque se acaban de exponer, la prueba 
de límites será más completa y, por tanto, tendrá una 
mayor probabilidad de detectar errores. 


17.6.4. Prueba de comparación 


Hay situaciones (por ejemplo, aviónica de aeronaves, 
control de planta nuclear) en las que la fiabilidad del 
software es algo absolutamente crítico. En ese tipo de 
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aplicaciones, a menudo se utiliza hardware y software 
redundante para minimizar la posibilidad de error. Cuan- 
do se desarrolla software redundante, varios equipos de 
ingeniería del software separados desarrollan versiones 
independientes de una aplicación, usando las mismas 
especificaciones. En esas situaciones, se deben probar 
todas las versiones con los mismos datos de prueba, para 
asegurar que todas proporcionan una salida idéntica. 
Luego, se ejecutan todas las versiones en paralelo y se 
hace una comparación en tiempo real de los resultados, 
para garantizar la consistencia. 

Con las lecciones aprendidas de los sistemas redun- 
dantes, los investigadores (por ejemplo, [BR187]) han 
sugerido que, para las aplicaciones críticas, se deben 
desarrollar versiones de software independientes, inclu- 
so aunque sólo se vaya a distribuir una de las versiones 
en el sistema final basado en computadora. Esas ver- 
siones independientes son la base de una técnica de prue- 
ba de caja negra denominada prueba de comparación 
oprueba mano a mano [KNI89]. 

Cuando se han producido múltiples implementacio- 
nes de la misma especificación, a cada versión del soft- 
ware se le proporciona como entrada los casos de prueba 
diseñados mediante alguna otra técnica de caja negra 
(por ejemplo, la partición equivalente). Si las salidas 
producidas por las distintas versiones son idénticas, se 
asume que todas las implementaciones son correctas. 
Si la salida es diferente, se investigan todas las aplica- 
ciones para determinarel defectoresponsable de la dife- 
rencia en una o más versiones. En la mayoría de los 
casos, la comparación de las salidas se puede llevar a 
cabo mediante una herramienta automática. 


17.6.5. Prueba de la tabla ortogonal 


Hay muchas aplicaciones en que el dominio de entrada 
es relativamente limitado. Es decir, el número de pará- 
metros de entrada es pequeño y los valores de cada uno 
de los parámetros está claramente delimitado. Cuando 
estos números son muy pequeños (por ejemplo, 3 pará- 
metros de entrada tomando 3 valores diferentes), es posi- 
ble considerar cada permutación de entrada y comprobar 
exhaustivamente el proceso del dominio de entrada. En 
cualquier caso, cuando el número de valores de entra- 
da crece y el número de valores diferentes para cada 
elemento de dato se incrementa, la prueba exhaustiva 
se hace impracticable o imposible. 


a 
e 


CLAVE 


la prueba de la tabla ortogonal permite diseñar casos 
de prueba que facilitan una coberturamáxima de prueba 
con un número razonable de casos de prueba. 


La prueba de la tabla ortogonal puede aplicarse a 
problemas en que el dominio de entrada es relativamente 
pequeño pero demasiado grande para posibilitar prue- 
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bas exhaustivas. El método de prueba de la tabla orto- 
gonal es particularmente útil al encontrar errores aso- 
ciados con fallos localizados —una categoría de error 
asociada con defectos de la lógica dentro de un com- 
ponente software —. 

Para ilustrar la diferencia entre la prueba de la tabla 
ortogonal y una aproximación más convencional «un 
elemento de entrada distinto cada vez», considerar un 
sistema que tiene tres elementos de entrada, X, Y y Z. 
Cada uno de estos elementos de entrada tiene tres valo- 
res diferentes. Hay 3* =27 posibles casos de prueba. 
Phadke [PHA97] sugiere una visión geométrica de los 
posibles casos de prueba asociados con X, Y y Z, 
según se ilustra en la Figura 17.10. Observando la 
figura, cada elemento de entrada en un momento dado 
puede modificarse secuencialmente en cada eje de 
entrada. 


Un elemento de entrada 
a la vez 


FIGURA 17.10. Una vista geométrica de los casos. 


Tabla ortogonal L9 


Esto da como resultado un alcance relativamente 
limitado al dominio de entrada (representado en la figu- 
ra por el cubo de la izquierda). 

Cuando se realiza la prueba de la tabla ortogonal, 
se crea una tabla ortogonal L9 de casos de prueba. La 
tabla ortogonal L9 tiene una «propiedad de equilibrio)) 
[PHA97]. Es decir, los casos de prueba (representados 
por puntos negros en la figura) están «uniformemen- 
te dispersos en el dominio de prueba», según se ilus- 
tra en el cubo de la derecha de la Figura 17.10. El 
alcance de la prueba por todo el dominio de entrada 
es más completo. 

Para ilustrar el uso de la tabla ortogonal L9, consi- 
derar la función enviar para una aplicación de un fax. 
Cuatro parámetros, P1, P2, P3 y P4 se pasan a la fun- 
ción enviar. Cada uno tiene tres valores diferentes. Por 
ejemplo, P1 toma los valores: 

Pl =1, enviar ahora 

P2 =2, enviar dentro de una hora 

P3 = 3, enviar después de media noche 
P2, P3, y P4 podrán tomar también los valores 1,2y 3, 
representando otras funciones enviar. 

Si se elige la estrategia de prueba «un elemento de 


entrada distinto cada vez», se especifica la siguiente 
secuencia de pruebas (P1,P2,P3,P4): (1,1, 1,1), 2,1,£,D, 
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(4,1,1,), (1,2,1,), (1,3,1,1), (1,1,2,1), (1,1,3,1), 
(1,1,1,2), y (1,1,1,3). Phadke [PHA97] valoraestos casos 
de prueba de la siguiente manera: 

Cada uno de estos casos de prueba son Útiles, Únicamente 
cuando estos parámetros de prueba no se influyen mutuamen- 
te. Pueden detectar fallos lógicos cuando el valor de un pará- 
metro produce un mal funcionamiento del software. Estos fallos 
pueden llamarse fallos de modalidad simple. El métodono pue- 
de detectar fallos lógicos que causen un mal funcionamiento 
cuando dos o más parámetros simultáneamente toman deter- 
minados valores; es decir, no sepueden detectar interacciones. 
Así, esta habilidad para detectar fallos es limitada. 


Dados un número relativamente pequeño de paráme- 
tros de entrada y valores diferentes, es posible realizar una 
prueba exhaustiva. El número de pruebas requeridas es 
3-8l —grande pero manejable —. Todos los fallos aso- 
ciados con la permutación de los datos seránencontrados, 
pero el esfuerzo requerido es relativamente alto. 


0 YUYOoONDNNNCAa ao y . 
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FIGURA 17.11. Unatabla ortogonal L9. 
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La prueba de la tabla ortogonal nos permite propor- 
cionar una buena cobertura de prueba con bastantes 
menos casos de prueba que en la estrategia exhaustiva. 
Una tabla ortogonal L9 para la función de envío del fax 
se describe en la Figura 17.11. 

Phadke [PHA97] valora el resultado de las prue- 
bas utilizando la tabla ortogonal de la siguiente 
manera: 


Detecta y aísla todos los fallos de modalidad sim- 
ple. Un fallo de modalidad simple es un problema que 
afecta a un solo parámetro. Por ejemplo, si todos los casos 
de prueba del factor P1= 1 causan una condición de error, 
nos encontramos con el fallo de modalidad simple. En los 
ejemplos de prueba 1,2 y 3 [Fig. 17.111 se encontrarán 
errores. Analizando la información en que las pruebas 
muestran errores, se puede identificar que valores del pará- 
metro causan el error. En este ejemplo, anotamos que las 
pruebas 1,2 y 3 causan un error, lo que permite aislar [el 
proceso lógico asociado con «enviar ahora» (Pl = 1)] la 
fuente del error. El aislamiento del fallo es importante para 
solucionar el error. 


Detecta todos los fallos de modalidad doble. Si exis- 
te un problema donde están afectados dos parámetros que 
intervienen conjuntamente, se llama fallo de modalidad 
doble. En efecto, un fallo de modalidad doble es una indi- 
cación de incompatibilidad o de imposibilidad de interac- 
ción entre dos parámetros. 


Fallos multimodales. Las tablas ortogonales [del tipo 
indicado] pueden asegurar la detección Únicamente de fallos 
de modalidad simple o doble. Sin embargo, muchos fallos 
en modalidad múltiple pueden ser detectados a través de 
estas pruebas. 


Se puede encontrar un estudio detallado sobre la 
prueba de tabla ortogonal en [PHA89]. 


A medida que el software de computadora se ha hecho 
más complejo, ha crecido también la necesidad de enfo- 
ques de pruebas especializados. Los métodos de prue- 
ba de caja blanca y de caja negra tratados en las 
Secciones 17.5 y 17.6 son aplicables a todos los entor- 
nos, arquitecturas y aplicaciones pero a veces se nece- 
sitan unas directrices y enfoques Únicos para las pruebas. 
En esta sección se estudian directrices de prueba para 
entornos, arquitecturas y aplicaciones especializadas 
que pueden encontrarse los ingenieros del software. 


17.7.1, Prueba de interfaces gráficas de usuario 
(IGUs) 


Las interfaces gráficas de usuario (IGUs) presentan 
interesantes desafíos para los ingenieros del softwa- 
re. Debido a los componentes reutilizables provistos 
como parte de los entornos de desarrollo de las GUI, 
la creación de la interfaz de usuario se ha convertido 
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en menos costosa en tiempo y más exacta. Al mismo 
tiempo, la complejidad de las IGUs ha aumentado, 
originando más dificultad en el diseño y ejecución de 
los casos de prueba. 


Una guía pora el diseño de IGU se presenta en 
el Capítulo 15. 


Dado que las IGUs modernas tienen la misma apa- 
riencia y filosofía, se pueden obtener una serie de 
pruebas estándar. Los grafos de modelado de estado 
finito (Sección 16.6.1) pueden ser utilizados para rea- 
lizar pruebas que vayan dirigidas sobre datos especí- 
ficos y programas objeto que sean relevantes para las 
IGUs. 

Considerando el gran número de permutaciones aso- 
ciadas con las operaciones IGU, sería necesario para 
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probar el utilizar herramientas automáticas. Una amplía 
lista de herramientas de prueba de IGU han aparecido 
en el mercado en los Últimos años. Para profundizar en 
el tema, ver el Capítulo 31, 


PruebalGU. 


17.7.2, Prueba de arquitectura cliente/servidor 


La arquitecturacliente/servidor (C/S) representa un desa- 
fío significativo para los responsables de la pruebas del 
software. La naturaleza distribuida de los entornos clien- 
te/servidor, los aspectos de rendimiento asociados con 
el proceso de transacciones, la presencia potencial de 
diferentes plataformas hardware, las complejidades de 
las comunicaciones de red, la necesidad de servir a múl- 
tiples clientes desde una base de datos centralizada (o 
en algunos casos, distribuida) y los requisitos de coor- 
dinación impuestos al servidor se combinan todos para 
hacer las pruebas de la arquitectura C/S y el software 
residente en ellas, considerablemente más difíciles que 
la prueba de aplicaciones individuales. De hecho, estu- 
dios recientes sobre la industria indican un significati- 
vo aumento en el tiempo invertido y los costes de las 
pruebas cuando se desarrollan entornos C/S. 


Lo ingenierío del software cliente /servidor se presento 
en el Capítulo 28. 


17.73. Prueba de la documentación y facilidades 
de ayuda 


El término apruebas del software» hace imaginarnos 
gran cantidad de casos de prueba preparados para eje- 
cutar programas de computadora y los datos que mane- 
jan. Recordando la definición de software presentada 
en el primer capítulo de este libro, es importante dar- 
se cuenta de que la prueba debe extenderse al tercer 
elemento de la configuración del software —Ja docu- 
mentación —. 

Los errores en la documentación pueden ser tan des- 
tructivos para la aceptación del programa, como los erro- 
res en los datos o en el código fuente. Nada es más 
frustrante que seguir fielmente el manual de usuario y 
obtenerresultados o comportamientosque no coinciden 
con los anticipados por el documento. Por esta razón, la 
prueba de la documentación debería ser una parte impor- 
tante de cualquier plan de pruebas del software. 

La prueba de la documentación se puede enfocar en 
dos fases. La primera fase, la revisión e inspección 
(Capítulo 8), examina el documento para comprobar la 
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claridad editorial. La segunda fase, la prueba en vivo, 
utiliza la documentaciónjunto al uso del programa real. 

Es sorprendente, pero la prueba en vivo de la docu- 
mentación se puede enfocar usando técnicas análogas 
a muchos de los métodos de prueba de caja negra estu- 
diados en la Sección 17.6. Se pueden emplear pruebas 
basadas en grafos para describir el empleo del progra- 
ma; se pueden emplear el análisis de la partición equi- 
valente o de los valores límites para definir varias clases 
de entradas e interacciones asociadas. 


17.7.4, Prueba de sistemas de tiempo-real 


La naturaleza asíncrona y dependiente del tiempo de 
muchas aplicaciones de tiempo real, añade un nuevo y 
potencialmente difícil elemento a la complejidad de las 
pruebas - e ltiempo—, El responsable del diseño de casos 
de prueba no sólo tiene que considerar los casos de prue- 
ba de caja blanca y de caja negra, sino también el trata- 
miento de sucesos (por ejemplo, procesamiento de 
interrupciones), la temporización de los datos y el para- 
lelismo de las tareas (procesos) que manejan los datos. En 
muchas situaciones, los datos de prueba proporcionados 
al sistemade tiempo real cuando se encuentraen un deter- 
minado estado darán un proceso correcto, mientras que al 
proporcionárselos en otro estado llevarán a un error. 


Sistemas de tiempo real. 


Por ejemplo, un software de tiempo real que controla 
una moderna fotocopiadora puede aceptar interrupcio- 
nes del operador (por ejemplo, el operador de la máqui- 
na pulsa teclas de control tales como «inicialización» u 
«oscurecimiento») sin error cuando la máquina se 
encuentra en el estado de hacer fotocopias (estado de 
«copia»). Esas mismas interrupciones del operador, 
cuando se producen estando la máquina en estado de 
«atasco», pueden producir un código de diagnóstico que 
indique la situación del atasco (un error). 

Además, la estrecha relación que existe entre el soft- 
ware de tiempo real y su entorno de hardware también 
puede introducir problemas en la prueba. Las pruebas 
del software deben considerar el impacto de los fallos 
del hardware sobre el proceso del software. Puede ser 
muy difícil simular de forma realista esos fallos. 

Todavía han de evolucionar mucho los métodos gene- 
rales de diseño de casos de prueba para sistemas de tiem- 
po real. Sin embargo, se puede proponer una estrategia 
en cuatro pasos: 


Prueba de tareas. El primer paso de la prueba de 
sistemas de tiempo real consiste en probar cada tarea 
independientemente. Es decir, se diseñan pruebas de 
caja blanca y de caja negra y se ejecutan para cada 
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tarea. Durante estas pruebas, cada tarea se ejecutainde- 
pendientemente.La prueba de la tarea ha de descubrir 
errores en la lógica y en el funcionamiento, pero no 
los errores de temporización o de comportamiento. 


Referencia 


BForum de Discusión de la Prueba del Software presenta temas 
de interés a los profesionalesque efectúanlo pruebo: 
wrw.ondaweb.com /HyperNews /get.cgi/forums/'sti.htm. 


Prueba de comportamiento. Utilizando modelos 
del sistema creados con herramientas CASE, es posi- 
ble simular el comportamiento del sistema en tiempo 
real y examinar su comportamiento como consecuen- 
cia de sucesos externos. Estas actividades de análisis 
pueden servir como base del diseño de casos de prue- 
ba que se llevan a cabo cuando se ha construido el soft- 
ware de tiempo real. Utilizando una técnica parecida 
ala partición equivalente (Sección 17.6.1), se pueden 
categorizar los sucesos (por ejemplo, interrupciones, 
señales de control, datos) para la prueba. Por ejemplo, 
los sucesos para la fotocopiadora pueden ser inte- 
rrupciones del usuario (por ejemplo, reinicialización 
del contador), interrupcionesmecánicas (porejemplo, 
atasco del papel), interrupciones del sistema (por ejem- 
plo, bajo nivel de tinta) y modos de fallo (por ejem- 
plo, rodillo excesivamente caliente). Se prueba cada 
uno de esos sucesos individualmente y se examina el 
comportamiento del sistema ejecutable para detectar 
errores que se produzcan como consecuenciadel pro- 
ceso asociado a esos sucesos. Se puede comparar el 
comportamiento del modelo del sistema (desarrolla- 
do durante el análisis) con el software ejecutable para 
ver si existe concordancia. Una vez que se ha proba- 
do cada clase de sucesos, al sistema se le presentan 
sucesos en un orden aleatorioy con una frecuenciaale- 
atoria. Se examina el comportamiento del software 
para detectar errores de comportamiento. 
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Prueba intertareas. Una vez que se han aislado 
los errores en las tareas individuales y en el com- 
portamiento del sistema, la prueba se dirige hacia 
los errores relativos al tiempo. Se prueban las tare- 
as asíncronas que se sabe que comunican con otras, 
con diferentes tasas de datos y cargas de proceso 
para determinar si se producen errores de sincronis- 
mo entre las tareas. Además, se prueban las tareas 
que se comunican mediante colas de mensajes O 
almacenes de datos, para detectar errores en el tama- 
ño de esas áreas de almacenamiento de datos. 


Prueba del sistema. El software y el hardware están 
integrados, por lo que se lleva a cabo una serie de prue- 
bas completas del sistema (Capítulo 18) para intentar 
descubrir errores en la interfaz software/hardware. 


La mayoría de los sistemas de tiempo real procesan 
interrupciones. Portanto, es esencial la prueba del mane- 
jo de estos sucesos lógicos. Usando el diagrama estado- 
transición y la especificación de control (Capítulo 12), el 
responsable de la prueba desarrolla una lista de todas las 
posibles interrupciones y del proceso que ocurre como 
consecuenciade la interrupción. Se diseñan después prue- 
bas para valorar las siguientes característicasdel sistema: 


¿Se han asignado y gestionado apropiadamente las 
prioridades de interrupción? 


¿Se gestiona correctamente el procesamiento para 
todas las interrupciones? 


¿Se ajusta a los requisitos el rendimiento (por ejem- 
plo, tiempo de proceso) de todos los procedimientos 
de gestión de interrupciones? 


¿Crea problemas de funcionamiento o rendimiento 
la llegada de un gran volumen de interrupciones en 
momentos críticos? 


Además, se deberían probar las áreas de datos glo- 
bales que se usan para transferir información como par- 
te del proceso de una interrupción para valorar el 
potencial de generación de efectos colaterales. 


El principal objetivo del diseño de casos de prueba es 
obtener un conjunto de pruebas que tengan la mayor 
probabilidad de descubrirlos defectos del software. Para 
llevar a cabo este objetivo, se usan dos categorías dife- 
rentes de técnicas de diseño de casos de prueba: prue- 
ba de caja blanca y prueba de caja negra. 

Las pruebas de caja blanca se centran en la estruc- 
tura de control del programa. Se obtienen casos de prue- 
ba que aseguren que durante la prueba se han ejecutado, 
por lo menos una vez, todas las sentencias del progra- 
ma y que se ejercitan todas las condiciones lógicas. La 
prueba del camino básico, una técnica de caja blanca, 
hace uso de grafos de programa (o matrices de grafos) 
para obtener el conjunto de pruebas linealmente inde- 
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pendientes que aseguren la total cobertura. La prueba 
de condiciones y del flujo de datos ejercita más aún la 
lógica del programa y la prueba de los bucles comple- 
menta a otras técnicas de caja blanca, proporcionando 
un procedimiento para ejercitar bucles de distintos gra- 
dos de complejidad. 

Heztel [HET84] describe la prueba de caja blanca 
como «prueba a pequeña escala». Esto se debe a que 
las pruebas de caja blanca que hemos considerado en 
este capítulo son típicamente aplicadas a pequeños 
componentes de programas (po ejemplo; módulos o 
pequeños grupos de módulos). Por otro lado, la prue- 
ba de caja negra amplía el enfoque y se puede deno- 
minar «prueba a gran escala». 
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Las pruebas de caja negra son diseñadas para validar 
los requisitos funcionales sin fijarse en el funcionamien- 
to interno de un programa. Las técnicas de prueba de caja 
negra se centran en el ámbito de información de un pro- 
grama, de forma que se proporcione una cobertura com- 
pleta de prueba. Los métodos de prueba basados en grafos 
exploran las relaciones entre los objetos del programa y 
su comportamiento. La partición equivalente divide el 
campo de entrada en clases de datos que tienden a ejerci- 
tar determinadas funciones del software. El análisis de 
valores límite prueba la habilidad del programa para mane- 
jar datos que se encuentran en los límites aceptables. La 
prueba de la tabla ortogonal suministra un método siste- 
mático y eficiente para probar sistemas con un número 
reducido de parámetros de entrada. 


Los métodos de prueba especializados comprenden una 
amplia gama de capacidades del software y áreas de apli- 
cación. Las interfaces gráficas de usuario, las arquitectu- 
ras cliente/servidor, la documentación y facilidades de 
ayuda, y los sistemas de tiempo real requieren directrices 
y técnicas especializadas para la prueba del software. 

A menudo, los desarrolladores de software experl- 
mentados dicen que «la prueba nunca termina, simple- 
mente se transfiere de usted (el ingeniero del software) 
al cliente: Cada vez que el cliente usa el programa, lle- 
va acabo una prueba.» Aplicando el diseño de casos de 
prueba, el ingeniero del software puede conseguir una 
prueba más completa y descubrir y corregir así el mayor 
número de errores antes de que comiencen las «prue- 
bas del cliente». 
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17.1. Myers [MYE79] usa el siguiente programa como auto- 
comprobación de su capacidad para especificar una prueba 
adecuada: un programa lee tres valores enteros. Los tres valo- 
res se interpretan como representación de la longitud de los 
tres lados de un triángulo. El programa imprime un mensaje 
indicando si el triángulo es escaleno, isósceles o equilátero. 
Desarrolle un conjunto de casos de prueba que considere que 
probará de forma adecuada este programa. 
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17.2. Diseñe e implemente el programa especificadoen el Pro- 
blema 17.1 (con tratamiento de errores cuando sea necesario). 
Obtenga un grafo de flujo para el programa y aplique la prue- 
ba del camino básico para desarrollar casos de prueba que 
garanticen la comprobación de todas las sentencias del pro- 
grama. Ejecute los casos y muestre sus resultados. 


17.3. ¿Se le ocurren algunos objetivos de prueba adicionales 
que no se hayan mencionado en la Sección 17.1.1? 


www.elsolucionario.net 


174. Aplique la técnica de prueba del camino básico a cual- 
quiera de los programas que haya implementado en los Pro- 
blemas 17.4a 17.11. 


175. Especifique, diseñe e implemente una herramienta de 
software que calcule la complejidad ciclomática para el len- 
guaje de programación que quiera. Utilice la matriz de grafos 
como estructura de datos operativa en el diseño. 

176. Lea a Beizer [BEI90] y determine cómo puede ampliar el 
programa desarrolladoen el Problema 17.5 para que incluya varios 
pesos de enlace. Amplíe la herramientapara que procese las pro- 
babilidadesde ejecución o los tiempos de proceso de enlaces. 
17.7. Use el enfoque de prueba de condiciones descrito en la 
Sección 17.5.1 para diseñar un conjunto de casos de prueba 
para el programa creado en el Problema 17.2. 

178. Mediante el enfoque de prueba de flujo de datos descri- 
to en la Sección 17.5.2, cree una lista de cadenas de defini- 
ción-uso para el programa creado en el Problema 17.2. 

17.9. Diseñe una herramienta automática que reconozca los 
bucles y los clasifique como indica la Sección 17.5.3. 

17.10. Amplíe la herramienta descrita en el Problema 17.9para 
que genere casos de prueba para cada categoría de bucle, cuan- 
do los encuentre. Será necesario llevar a cabo esta función de 
forma interactivacon el encargado de la prueba. 

17.11. Dé por lo menos tres ejemplos en los que la prueba de 
caja negra pueda dar la impresión de que «todo está bien», 


aaa AS DE PRUEBA DEL SOFTWARE 


mientras que la prueba de caja blanca pudiera descubrir erro- 
res. Indique por lo menos tres ejemplos en los que la prueba 
de caja blanca pueda dar la impresión de que «todo está bien», 
mientras que la prueba de caja negra pudiera descubrirerrores. 
17.12. ¿Podría una prueba exhaustiva (incluso si fuera posi- 
ble para pequeños programas) garantizar que un programa es 
al 100 por 100 correcto? 

17.13. Usando el método de la partición equivalente, obtenga 
un conjunto de casos de prueba para el sistema HogarSeguro 
descrito anteriormente en el libro. 

17.14. Mediante el análisis de valores límite, obtenga un con- 
junto de casos de prueba para el sistema SSRB descrito en el 
Problema 12.13. 

17.15. Investigueun poco y escribaun breve documento sobre 
el mecanismo de generación de tablas ortogonales para la prue- 
ba de datos. 

17.16. Seleccione una IGU específica para un programa con 
el que esté familiarizado y diseñe una serie de pruebas para 
ejercitar la IGU. 

17.17. Investigue en un sistema Cliente/Servidor que le sea 
familiar. Desarrolle un conjunto de escenarios de usuario y 
genere un perfil operacional para el sistema. 

17.18. Pruebe un manual de usuario (o una facilidad de ayu- 
da) de una aplicación que utilice frecuentemente. Encuentre 
al menos un error en la documentación. 


La ingeniería del software presenta tanto desafíos técnicos 
como de gestión. Los libros de Black(Managing the Testing Pro- 
cess, Microsoft Press, 1999), Dustin, Rashka y Paul (Testpro- 
cess Improvement: Step-By-Step Guide to Structured Testing, 
Addison-Wesley, 1999), Peny (Surviving the Top Ten Challen- 
ges of Software Testing: A People-Oriented Approach, Dorset 
House, 1997), y Kit y Finzi (SoftwareTesting in the Real World: 
Improving the Process, Addison-Wesley, 1995) orientan sobre 
las necesidades de gestión y de procesos. 

Para aquellos lectores que deseen“información adicional 
sobre la tecnología de prueba del software, existen varios 
libros excelentes. Kaner, Nguyen y Falk (Testing Computer 
Software Wiley,1999), Hutcheson (Sofiare Testing Methods 
and Metrics: The Most Important Test, McGraw-Hill, 1997), 
Marick (The Craft of Software Testing: Subsystem Testing 
Including Object-Based and Object-Oriented Testing, Pren- 
tice-Hall, 1995), Jorgensen (Software Testing: A Craftman's 
Approach, CRC Press, 1995) presentan estudios sobre los 
métodos y estrategias de prueba. 

Myers [MYE79] permanece como un texto clásico, cubrien- 
do con considerable detalle las técnicas de caja negra. Beizer 
[BEI90] da una amplia cobertura de las técnicas de caja blanca, 
introduciendo cierto nivel de rigor matemático que a menudo se 
echa en falta en otros tratados sobre la prueba. Su último libro 
[BEI95] presenta un tratado conciso de métodos importantes. 
Perry (EffectiveMethodsfor Software Testing,Wiley-QED, 1995), 
y Freeman y Voas (SofiareAssesment: Reliability, Sfety, Tes- 
tability, Wiley, 1995)presentan buenas introducciones a lasestra- 
tegias y tácticas de las pruebas. Mosley (The Handbook of MIS 
Application Software Testing, Prentice-Hall, 1993) estudia aspec- 
tosde las pruebas para grandes sistemas de información, y Marks 
(Testing Very Big Systems, McGraw-Hill, 1992)estudia los aspec- 
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tos especiales que deben considerarse cuando se prueban gran- 
des sistemas de programación. 

La prueba del software es un recurso en continua activi- 
dad. Es por estarazón por lo que muchas organizacionesauto- 
matizan parte de los procesos de prueba. Los libros de Dustin, 
Rashka y Poston (Automated Software Testing: Introduction, 
Management, and Performance, Addison-Wesley, 1999) y 
Poston (Automating Specification-Based Software Testing, 
TEEE Computer Society, 1996) hablan sobre herramientas, 
estrategias y métodos para automatizar la prueba. Una exce- 
lente fuente de información sobre herramientas automatiza- 
das de prueba la encontramos en Testing Tools Reference 
Guide (Software Quality Engineering, Inc., Jacksonville, FL, 
actualizada anualmente). Este directorio contiene descrip- 
ciones de cientos de herramientas de prueba, clasificadas por 
tipo de prueba, plataforma hardware y soporte software. 

Algunos libros tratan los métodos y estrategias de prueba 
en áreas de aplicación especializada. Gardiner (Testing Safety- 
Related Software: A Practical Handbook, Springer Verlag, 
1999) ha editado un libro que trata la prueba en sistemas de 
seguridad crítica. Mosley (Client/Server Software Testing on 
the Desk Top and the Web, Prentice Hall, 1999) trata la prue- 
ba para clientes, servidores y componentes en red. Rubin 
(Handbookof Usability Testing, Wiley, 1994) ha escrito una 
guía útil para lo que necesitan manejar interfaces humanas. 

Una amplia variedad de fuentes de información sobre 
pruebas del software y elementos relacionados están 
disponibles en internet. Una lista actualizada de refe- 
rencias a páginas web que son relevantes sobre los con- 
ceptos de prueba, métodos y estrategias se pueden 
encontrar en http://www.pressman5.com. 
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CAPÍTULO 


18 


ESTRATEGIAS DE PRUEBA 
DE SOFTWARE 


NA estrategia de prueba del software integra las técnicas de diseño de casos de prueba 

en una serie de pasos bien planificados que dan como resultado una correcta construc- 

ción del software. La estrategia proporciona un mapa que describe los pasos que hay 
que llevar a cabo como parte de la prueba, cuándo se deben planificar y realizar esos pasos, y 
cuánto esfuerzo, tiempo y recursos se van a requerir. Por tanto, cualquier estrategia de prueba 
debe incorporar la planificación de la prueba, el diseño de casos de prueba, la ejecución de las 
pruebas y la agrupación y evaluación de los datos resultantes. 

Una estrategia de prueba del software debe ser suficientemente flexible para promover la 
creatividad y la adaptabilidad necesarias para adecuar la prueba a todos los grandes sistemas 
basados en software. Al mismo tiempo, la estrategia debe ser suficientementerígida para pro- 
mover un seguimiento razonable de la planificación y la gestión a medida que progresa el pro- 
yecto. Shooman [SHO83] trata estas cuestiones: 


En muchos aspectos, la prueba es un proceso individualista, y el número de tipos diferentes de pruebas 
varía tanto como los diferentes enfoques de desarrollo. Durante muchos años, nuestra Única defensa contra 
los errores de programación era un cuidadoso diseño y la propia inteligencia del programador. Ahora nos 
encontramos en una era en la que las técnicas modernas de diseño [y las revisiones técnicas formales] nos 
ayudan áreducir el número de errores iniciales que se encuentran en el código de forma inherente. De for- 
ma similar, los diferentes métodos de prueba están empezando a agruparse en varias filosofías y enfoques 


diferentes. 


VISTAZO RÁPIDO 


1é es? El diseño efectivo de casos de 

*' prueba (Capítulo 17) es importante, 

A "pero también lo es la estrategia para 

—gúurutilización. ¿Se deberá desarrollar 

+ un plan formal para estas pruebas?. 

¿Se deberá probar el programa ínte- 

“: gramente o ejecutar pruebas solamen- 

«fe sobre una parte pequeña del mismo? 

: ¿Se deberán ejecutar pruebas de regre- 
sión cuando se añadan nuevos com- 
ponentes al sistema? ¿Cuándo se 
deberá involucrar al cliente? Estas y 
otras muchas cuestionesserán contes- 
“tadas cuando desarrolles una estrate- 

. glade prueba del software. 

¿Quién lo hace? El jefe del proyecto, los 
ingenieros del software y los especia- 
listas en pruebas. 

¿Por qué es importante? En el pro- 
yecto, la prueba a veces requiere más 
esfuerzoque cualquier otra actividad 
delaingeniena del software. Sise efec- 
táa sin un plan, el tiempo se desapro- 


vecha y el esfuerzo es consumido inne- 
cesariamente y, en el peor de los casos, 
los errores inadvertidos quedarán sin 
detectar. Por tanto, parece razonable 
establecer una estrategia sistemática 
para probar el software. 

¿Cuáles son los pasos? La prueba 
comienza por d opequeño» y progresa 
hacia «lo grande». Por esta razón, debe- 
mos comenzar las primeras pruebas 
sobre el componente elemental y apli- 
car sobre él pruebas de caja blanca y 
de caja negra para descubrir errores 
en la lógica y en la funcionalidad del 
programa. Después de que los compo- 
nentes elementales hayan sido apro- 


bados, procederemosa suintegración. 


Las pruebas seefectuarán conformeel 
software se vaya construyendo. 
Finalmente, una serie de pruebas de 
alto nivel serán ejecutadas una vez el 
programa esté totalmente preparado 
para suoperatividad. 


Estas pruebas están diseñadas para 
descubrir errores en los requisitos. 


¿Cuál es el producto obtenido? El 
equipo de trabajo que desarrolla el 
software documenta la especificación 
de la prueba basándose en la defini- 
ción del plan que establece la estrate- 
gia general y del procedimiento que 
específicamente describe los pasos a 
seguir y las pruebas a realizar. 


¿Cómo puedo estar seguro de que 
lo he hecho correctamente? La. 
revisión de la especificación de la” 
prueba es previa a la realización de la 
prueba. Se debe valorar la completi- 
tud de 108 casos de prueba y de las 
tareas de la prueba. Un plan y un pro- 


cedimiento de prueba efectivopermi- 
tirá una construcción ordenada del 


software y el descubrimiento de erro- 
res €n cada etapa del proceso de cons- 


trucción. 


Estas «filosofías y enfoques» constituyen lo que nosotros llamaremos estrategia. En el Capí- 
tulo 17 se presentó la tecnología de prueba del software'. En este capítulo centraremos nuestra 
atención en las estrategias de prueba del software. 


1 Las pruebas de sistemas orientados a objetos se estudian en el Capítulo 23. 
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INGENIERÍA DEL SOFTWARE. UN ENFUQUE PRACTICO 


Las pruebas son un conjunto de actividades que se pue- 
den planificar por adelantado y llevar a cabo sistemáti- 
camente. Por esta razón, se debe definir en el proceso 
de la ingeniería del software una plantilla para las prue- 
bas del software: un conjunto de pasos en los que poda- 
mos situar los métodos específicos de diseño de casos 
de prueba. 

Se han propuesto varias estrategias de prueba del 
software en distintos libros. Todas proporcionan al inge- 
niero del software una plantilla para la prueba y todas 
tienen las siguientes características generales: 
+. Las pruebas comienzan a nivel de módulo” y traba- 
jan «hacia fuera», hacia la integración de todo el sis- 
tema basado en computadora. 

Según el momento, son apropiadas diferentes técni- 
cas de prueba. 

La prueba la lleva a cabo el responsable del desa- 
rrollo del software y (para grandes proyectos) un 
grupo independiente de pruebas. 

La prueba y la depuración son actividades diferen- 
tes, pero la depuración se debe incluir en cualquier 
estrategia de prueba. 


Una estrategia de prueba del software debe incluir 
pruebas de bajo nivel que verifiquen que todos los 
pequeños segmentos de código fuente se han imple- 
mentado correctamente, así como pruebas de alto nivel 
que validen las principales funciones del sistema frente 
a los requisitos del cliente. Una estrategia debe propor- 
cionar una guía al profesional y proporcionar un con- 
junto de hitos para eljefe de proyecto. Debido a que los 
pasos de la estrategia de prueba se dan a la vez cuando 
aumenta la presión de los plazos fijados, se debe poder 
medir el progreso y los problemas deben aparecer lo 
antes posible. 


Referencia Web 
Información Útil sobre las estrotegiosde pruebo del software 


es suministrodo en el informe sobre la Pruebo del Software 
ennwww.ondaweb.com/sti/newsHr.htm 


18.1.1. Verificación y validación 


La prueba del software es un elemento de un tema más 
amplio que, a menudo, es conocido como verificación 
y validación (V82V). La verificación se refiere al con- 
junto de actividades que aseguran que el software imple- 
menta correctamente una función específica. La 
validación se refiere a un conjunto diferente de activi- 
dades que aseguran que el software construido se ajus- 


2 Para los sistemas orientados a objetos, las pruebas empiezan a nivel 
de clase O de objeto. Vea más detalles en el Capítulo23. 


306 


ta a los requisitos del cliente. Bohem [BOE8]1] lo defi- 
ne de otra forma: 


Verificación:«¿Estamos construyendo el producto correc- 
tamente?» 


Validación:«¿Estamos construyendoel producto correcto?» 


La definición de VéV comprendemuchas de las acti- 
vidades a las que nos hemos referido como garantía de 
calidad del software (SQA”). 

La verificación y la validación abarcan una amplia 
lista de actividades SQA que incluye: revisiones téc- 
nicas formales, auditorías de calidad y de configura- 
ción, monitorización de rendimientos, simulación, 
estudios de factibilidad, revisión de la documenta- 
ción, revisión de la base de datos, análisis algorítmi- 
co, pruebas de desarrollo, pruebas de validación y 
pruebas de instalación [WAL89]. A pesar de que las 
actividades de prueba tienen un papel muy impor- 
tante en V£V, muchas otras actividades son también 
necesarias. 


Las actividades SQA son estudiadas en detalle en el 
Copítulo 8, 


Las pruebas constituyen el último bastión desde el 
que se puede evaluar la calidad y, de forma más prag- 
mática, descubrir los errores. Pero las pruebas no deben 
ser vistas como una red de seguridad. Como se suele 
decir: «No se puede probar la calidad. Si no está ahí 
antes de comenzar la prueba, no estará cuando se ter- 
mine.» La calidad se incorpora en el software durante 
el proceso de ingeniería del software. La aplicación ade- 
cuada de los métodos y de las herramientas, las revi- 
siones técnicas formales efectivas y una sólida gestión 
y medición, conducen a la calidad, que se confirma 
durante las pruebas. 


porte inevitoble de cualquier 
para desarrollar un sistema 


Miller [MIL77] relaciona la prueba del software con 
la garantía de calidad al establecer que «la motivación 
subyacente de la prueba de programas es confirmar la 
calidad del software con métodos que se pueden apli- 
car de forma económicay efectiva, tanto a grandes como 
a pequeños sistemas». 


* Por lo habitual de su utilización mantenemos el termino ingles SQA 
(SoftwareQuality Assurance). 
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18.1.2, Organización para las pruebas del software 


En cualquier proyecto de software existe un conflicto 
de intereses inherente que aparece cuando comienzan 
las pruebas. Se pide a la gente que ha construido el soft- 
ware que lo pruebe. Esto parece totalmente inofensivo: 
después de todo, ¿quién puede conocer mejor un pro- 
grama que los que lo han desarrollado? Desgraciada- 
mente, esos mismos programadores tienen un gran 
interés en demostrar que el programa está libre de erro- 
res, que funciona de acuerdo con las especificaciones 
del cliente y que estará listo de acuerdo con los plazos 
y el presupuesto. Cada uno de estos intereses se con- 
vierte en inconveniente a la hora de encontrar errores a 
lo largo del proceso de prueba. 

Desde un punto de vista psicológico, el análisis y el 
diseño del software (juntocon la codificación) son tareas 
constructivas. El ingeniero del software crea un progra- 
ma de computadora, su documentación y sus estructuras 
de datos asociadas. Al igual que cualquier constructor,el 
ingeniero del software está orgulloso del edificioque aca- 
ba de construir y se enfrenta a cualquiera que intente 
sacarle defectos. 

Cuando comienza la prueba, aparece una sutil, aun- 
que firme intención de «romper» lo que el ingeniero del 
software ha construido. Desde el punto de vista del cons- 
tructor, la prueba se puede considerar (psicológicamente) 
destructiva, Por tanto, el constructor anda con cuidado, 
diseñando y ejecutando pruebas que demuestren que el 
programa funciona, en lugar de detectar errores. Des- 
graciadamente, los errores seguirán estando. Y si el inge- 
niero del software no los encuentra, ¡el cliente si lo hará! 

A menudo, existen ciertos malentendidosque se pue- 
den deducir equivocadamente de la anterior discusión: 
(Del responsable del desarrollo no debería entrar en el 
proceso de prueba; (2) el software debe ser «puesto a 
salvo» de extraños que puedan probarlo de forma des- 
piadada; (3) los encargados de la prueba sólo aparecen 
en el proyecto cuando comienzan las etapas de prueba. 
Todas estas frases son incorrectas. 

El responsable del desarrollo del software siempre 
es responsable de probar las unidades individuales 
(módulos)del programa, asegurándose de que cada una 
lleva a cabo la función para la que fue diseñada. En 
muchos casos, también se encargará de la prueba de 
integración, el paso de las pruebas que lleva a la cons- 
trucción (y prueba) de la estructura total del sistema. 
Sólo una vez que la arquitectura del software esté com- 
pleta entra en juego un grupo independiente de prueba. 


a 
SS 
Mu VE 


Un grupo independientede prueba no tiene el (conflicto 
de intereses) que tienen los desarrolladores del software. 


El papel del grupo independiente de prueba (GIP) 
es eliminar los inherentes problemas asociados con el 
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hecho de permitir al constructor que pruebe lo que ha 
construido. Una prueba independiente elimina el con- 
flicto de intereses que, de otro modo, estaría presen- 
te. Después de todo, al personal del equipo que forma 
el grupo independiente se le paga para que encuentre 
errores. 

Sin embargo, el responsable del desarrolladodel soft- 
ware no entrega simplemente el programa al GIP y se 
desentiende. El responsable del desarrollado y el GIP 
trabajan estrechamente a lo largo del proyecto de soft- 
ware para asegurar que serealizan pruebas exhaustivas. 
Mientras se realiza la prueba, el desarrollador debe estar 
disponible para corregir los errores que se van descu- 


briendo. 
Cons 


Sino existe un GIP entu organización, 
tendrás que asumir su punto de vista. 
Cuando pruebes, intenta destrozarel software. 


El GIP es parte del equipo del proyecto de desarro- 
llo de software en el sentido de que se ve implicado 
durante el proceso de especificación y sigue implicado 
(planificación y especificación de los procedimientos 
de prueba) a lo largo de un gran proyecto. Sin embar- 
go, en muchos casos, el GIP informa a la organización 
de garantía de calidad del software, consiguiendo de 
este modo un grado de independenciaque no sería posi- 
ble si fuera una parte de la organización de desarrollo 
del software. 


18.13. Una estrategia de prueba del software 


El proceso de ingeniería del software se puede ver como 
una espiral, como se ilustra en la Figura 18.1. Inicial- 
mente, la ingeniería de sistemas define el papel del soft- 
ware y conduce al análisis de los requisitos del software, 
donde se establece el dominio de información, la fun- 
ción, el comportamiento, el rendimiento, las restriccio- 
nes y los criterios de validación del software. Al 
movemos hacia el interior de la espiral, llegamos al dise- 
ño y, por último, a la codificación. Para desarrollar soft- 
ware de computadora, damos vueltas en espiral a través 
de una serie de flujos o líneas que disminuyen el nivel 
de abstracción en cada vuelta, 


Qué es la estrategia global 
" para la prueba del software? 


También se puede ver la estrategia para la prueba del 
software en el contexto de la espiral (Fig. 18.1).La prue- 
ba de unidad comienza en el vértice de la espiral y se 
centra en cada unidad del software, tal como está imple- 
mentada en código fuente. La prueba avanza, al mover- 
nos hacia fuera de la espiral, hasta llegar a laprueba de 
integración, donde el foco de atención es el diseño y la 
construcción de la arquitecturadel software. Dando otra 
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vuelta por la espiral hacia fuera, encontramos laprue- 
ba de validación, donde se validan los requisitos esta- 
blecidos como parte del análisis de requisitos del 
software, comparándolos con el sistema que ha sido 
construido. Finalmente, llegamos a laprueba del siste- 
ma, en la que se prueban como un todo el software y 
otros elementos del sistema. Para probar software de 
computadora nos movemos hacia fuera por una espiral 
que, a cada vuelta, aumenta el alcance de la prueba. 
Prueba del sistem 


Prueba de validación, 


Prueba de integración nd a 


“Ingeniería del sistema 


FIGURA 18.1. Estrategia de prueba. 


Si consideramos el proceso desde el punto de vista pro- 
cedimental, la prueba, en el contexto de la ingeniería del 
software, realmente es una serie de cuatro pasos que se 
llevan a cabo secuencialmente. Esos pasos se muestran 
en la Figura 18.2. Inicialmente, la prueba se centra en cada 
módulo individualmente, asegurando que funcionan ade- 
cuadamente como una unidad. De ahí el nombre deprue- 
ba de unidad. La prueba de unidad hace un uso intensivo 
de las técnicas de prueba de caja blanca, ejercitando cami- 
nos específicos de la estructura de control del módulo para 
asegurar un alcance completo y una detección máxima de 
errores. A continuación, se deben ensamblaro integrar los 
módulos para formar el paquete de software completo. La 
prueba de integración se dirige a todos los aspectos aso- 
ciados con el doble problema de verificación y de cons- 
trucción del programa. Durante la integración, las técnicas 
que más prevalecen son las de diseño de casos de prueba 
de caja negra, aunque se pueden llevar a cabo algunas 
pruebas de caja blanca con el fin de asegurar que se cubren 
los principales caminos de control. Después de que el soft- 
ware se ha integrado (construido), se dirigen un conjun- 
to de pruebas de alto nivel. Se deben comprobar los 
criterios de validación (establecidos durante el análisis de 
requisitos).La prueba de validación proporciona una segu- 
ridad final de que el software satisface todos los requisi- 
tos funcionales, de comportamiento y de rendimiento. 
Durante la validación se usan exclusivamente técnicas de 
prueba de caja negra. 


Referencia cruzada 


Los técnicas de pruebo de cojo blanca y cojo negra 
se estudian en el Capítulo 17, 


El último paso de prueba de alto nivel queda fuera 
de los límites de la ingeniería del software, entrando en 
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el más amplio contexto de la ingeniería de sistemas de 
computadora. 

El software, una vez validado, se debe combinar con 
otros elementos del sistema (por ejemplo, hardware, gen- 
te, bases de datos). La prueba del sistema verifica que 
cada elemento encaja de forma adecuada y que se alcan- 
za la funcionalidad y el rendimiento del sistema total. 


Pruebas 


Requisitos de alto nivel 


Diseño 


Codificación k 


«Dirección 
de la prueban 


FIGURA 18.2. Etapas en la prueba del software. 


18.1.4. Criterios para completar la prueba 


Cada vez que se tratan las pruebas del software surge 
una pregunta clásica: ¿Cuando hemos terminado las 
pruebas?, ¿cómo sabemos que hemos probado lo sufi- 
ciente? Desgraciadamente, no hay una respuesta defi- 
nitiva a esta pregunta, pero hay algunas respuestas 
prácticas y nuevos intentos de base empírica. 


¿Cuándo debemos probar? 


Una respuesta a la pregunta anterior es: «La prueba 
nunca termina, ya que el responsable del desarrollo del 
software carga O pasa el problema al cliente.» Cada vez 
que el cliente/usuario ejecuta un programa de compu- 
tadora, dicho programa se está probando con un nuevo 
conjunto de datos. Este importante hecho subraya la 
importancia de otras actividades de garantía de calidad 
del software. Otra respuesta (algo cínica, pero sin embar 
go cierta) es: «Se termina la prueba cuando se agotael 
tiempo o el dinero disponible para tal efecto.» 

Aunque algunos profesionales se sirvan de estas res- 
puestas como argumento, un ingeniero del software 
necesita un criterio más riguroso para determinar cuan- 
do se ha realizado la prueba suficiente. Musa y Acker- 
man [MUS89] sugieren una respuesta basada en un 
criterio estadístico: «No, no podemos tener la absoluta 
certeza de que el software nunca fallará, pero en base a 
un modelo estadístico de corte teórico y validado expe- 
rimentalmente, hemos realizado las pruebas suficientes 
para decir, con un 95 por 100 de certeza, que la proba- 
bilidad de funcionamiento libre de fallo de 1.000 horas 
de CPU, en un entorno definido de forma probabilísti- 
ca, es al menos 0,995.» 


Mediante el modelado estadístico y la teoría de fiabi- 
lidad del software, se pueden desarrollar modelos de fallos 
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del software (descubiertos durante las pruebas) como una 
función del tiempo de ejecución. Una versión del mode- 
lode fallos, denominadomodelo logarítmico de Poisson 
de tiempo de ejecución, toma la siguiente forma: 


Ki) =(1p) In [(1,pt +1)] (18.1) 


donde 


K(t) número acumulado de fallos que se espera que 
se produzcan una vez que se ha probado el soft- 
ware durante una cierta cantidad de tiempo de 
ejecución t, 

la intensidad de fallos inicial del software (fallos 
por unidad de tiempo) al principio de la prueba 
la reducción exponencial de intensidad de fallo 
a medida que se encuentran los errores y se van 
haciendo las correcciones. 


La intensidad de fallos instantánea, (t)se puede obte- 
ner mediante la derivada de f(t): 


l()= 191 (ly pt +1) (18.2) 


Mediante la relación de la ecuación (18.2), los que 
realizan las pruebas pueden predecir la disminución de 
errores a medida que estas avanzan. La intensidad de error 
real se puede trazar junto a la curva predecida (Fig. 18.3). 
Si los datos reales recopilados durante la prueba y el 
modelo logarítmico de Poisson de tiempo de ejecución 
están razonablemente cerca unos de otros, sobre un núme- 
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ro de puntos de datos, el modelo se puede usar para pre- 
decir el tiempo de prueba total requerido para alcanzar 
una intensidad de fallos aceptablemente baja. 


? ES 
a | Ml Datos recogidos durante la prueba] 


Intensidad de fallos prevista, / (t) 


cal s gos hora de poleba 


Tiempo de ejecución, t 


FIGURA 18.3. Intensidad de fallos en función del tiempo 
de ejecución. 


Mediante la agrupación de métricas durante la prue- 
ba del software y haciendo uso de los modelos de fia- 
bilidad del software existentes, es posible desarrollar 
directrices importantes para responder a la pregunta: 
¿cuándo terminamos la prueba? No hay duda que toda- 
vía queda mucho trabajo por hacer antes de que se pue- 
dan establecer reglas cuantitativas para la prueba, pero 
los enfoquesempíricos que existen actualmente son con- 
siderablemente mejores que la pura intuición. 


Más adelante, en este capítulo, exploramos una estrate- 
gla sistemática para la prueba del software. Pero inclu- 
so la mejor estrategia fracasará si no se tratan una serie 
de aspectos invalidantes. Tom Gilb [GIL95] plantea que 
se deben abordar los siguientes puntos si se desea Imple- 
mentar con éxito una estrategia de prueba del software: 


¿Qué debemos hacer para 
* definir una estrategia de 
prueba correcta? 


Especificar los requisitos del producto de manera 
cuantificable mucho antes de que comiencen las 
pruebas. Aunque el objetivo principal de la prueba 
es encontrar errores, una buena estrategia de prueba 
también evalúa otras características de la calidad, 
tales como la portabilidad, facilidad de manteni- 
miento y facilidad de uso (Capítulo 19). Todo esto 
debería especificarsede manera que sea medible para 
que los resultados de la prueba no sean ambiguos. 


Establecer los objetivos de la prueba de manera 
explícita. Se deberían establecer en términos medi- 
bles los objetivos específicos de la prueba. Por ejem- 
plo, la efectividad de la prueba, la cobertura de la 
prueba, tiempo medio de fallo, el coste para encon- 
trar y arreglar errores, densidad de fallos remanente 
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O frecuencia de ocurrencia, y horas de trabajo por 
prueba de regresión deberían establecerse dentro de 
la planificación de la prueba [GIL95)]. 


Comprender qué usuarios van a manejar el soft- 
ware y desarrollar un perfil para cada categoría de 
usuario. Usar casos que describan el escenario de 
interacción para cada clase de usuario pudiendo redu- 
cir el esfuerzo general de prueba concentrando la 
prueba en el empleo real del producto. 


Referencia cruzada 


los casos de usa describen un escenario para usar 
el software y se estudianen el Capo 11. 


Desarrollar un plan de prueba que haga hinca- 
pié en la «prueba de ciclo rápido». Gilb [GIL95] 
recomienda que un equipo de ingeniería del software 
«aprenda a probar en ciclos rápidos (2 por 100 del 
esfuerzo del proyecto) de incrementos de funciona- 
lidad y/o mejora de la calidad Útiles para el cliente, 
y que se puedan probar sobre el terreno». La reali- 
mentación generada por estas pruebas de ciclorápido 
puede usarse para controlar los niveles de calidad y 
las correspondientes estrategias de prueba. 
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delos requisitos percibidos por el usuario 
¿0 la inspección de una construcción 

abajo realizado por un decorador 

lentos, vigos y fontanería. 


Construir un software «robusto» diseñado para 
probarse a sí mismo. El software debería diseñarse 
de manera que use técnicas de depuración antierrores 
(Sección 18.3.1). Es decir, el software debería ser 
capaz de diagnosticar ciertas clases de errores. Ade- 
más, el diseño debería incluir pruebas automatizadas 
y pruebas de regresión. 


Usar revisiones técnicas formales efectivas 
comofiltro antes de laprueba. Las revisiones téc- 


nicas formales (Capítulo 8) pueden ser tan efecti- 
vas como las pruebas en el descubrimiento de erro- 
res. Por este motivo, las revisiones pueden reducir 
la cantidad de esfuerzo de prueba necesaria para 
producir software de alta calidad. 


Llevar a cabo revisiones técnicasformales para 
evaluar la estrategia de prueba y lospropios casos 
deprueba. Las revisiones técnicas formales pueden 
descubrir inconsistencias, omisiones y errores cla- 
ros en el enfoque de la prueba. Esto ahorra tiempo 
y también mejora la calidad del producto. 


Desarrollar un enfoque de mejora continua al 
proceso de prueba. Debería medirse la estrategia 
de prueba. Las métricas agrupadas durante la 
prueba deberían usarse como parte de un enfoque 
estadístico de control del proceso para la prueba 
del software. 


La prueba de unidad centra el proceso de verificación 
en la menor unidad del diseño del software: el compo- 
nente software o módulo. 


18.3.1. Consideracionessobre la prueba de unidad 


Las pruebas que se dan como parte de la prueba de uni- 
dad están esquemáticamente ilustradas en la Figura 18.4. 
Se prueba la interfaz del módulo para asegurar que la 
información fluye de forma adecuada hacia y desde la 
unidad de programa que está siendo probada. Se exa- 
minan las estructuras de datos locales para asegurar que 
los datos que se mantienen temporalmente conservan 
su integridad durante todos los pasos de ejecución del 
algoritmo. Se prueban las condiciones límite para ase- 
gurar que el módulo funciona correctamenteen los lími- 
tes establecidos como restricciones de procesamiento. 
Se ejercitan todos los caminos independientes (cami- 
nos básicos) de la estructura de control con el fin de ase- 
gurar que todas las sentencias del módulo se ejecutan 
por lo menos una vez. Y, finalmente, se prueban todos 
los caminos de manejo de errores. 


Prueba de Unidad. 


Antes de iniciar cualquier otra prueba es preciso pro- 
bar el flujo de datos de la interfaz del módulo. Si los 
datos no entran correctamente, todas las demás pruebas 
no tienen sentido. Además de las estructuras de datos 
locales, durante la prueba de unidad se debe comprobar 
(en la medida de lo posible) el impacto de los datos glo- 
bales sobre el módulo. 
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Interiaz 
Ao Estructuras de datos locales 
Condiciones límite 
Caminos independientes 


Caminos de manejo de errores 


Casos 
de prueba 


FIGURA 18.4. Prueba de unidad. 


Durante la prueba de unidad, la comprobación selec- 
tiva de los caminos de ejecución es una tarea esencial. 
Se deben diseñar casos de prueba para detectar errores 
debidos a cálculos incorrectos, comparacionesincorrectas 
o flujos de control inapropiados. Las pruebas del cami- 
no básico y de bucles son técnicas muy efectivas para 
descubrir una gran cantidad de errores en los caminos. 


¿Qué errores son los mós comunes 
durante la prueba de unidad? 


Entre los errores más comunes en los cálculos están: 
(1) precedencia aritmética incorrectao mal interpretada; 
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(2)operacionesde modo mezcladas; (3) inicializaciones 
incorrectas; (4)falta de precisión; (5) incorrecta repre- 
sentación simbólica de una expresión. Las comparacio- 
nes y el flujo de control están fuertemente emparejadas 
(porejemplo, el flujo de control cambia frecuentemente 
tras una comparación). Los casos de prueba deben des- 
cubrir errores como: (1) comparaciones ente tipos de 
datos distintos; (2) operadores lógicos o de precedencia 
incorrectos; (3) igualdad esperada cuando los errores de 
precisión la hacen poco probable; (4) variables o com- 
paraciones incorrectas; (5 )terminación de bucles ina- 
propiada O inexistente; (6) fallo de salida cuando se 
encuentra una iteración divergente, y (7) variables de 
bucles modificadas de forma inapropiada. 

Un buen diseño exige que las condiciones de error 
sean previstas de antemano y que se dispongan unos 
caminos de manejo de errores que redirijan o termi- 
nen de una forma limpia el proceso cuando se dé un 
error. Yourdon [YOU75] llama a este enfoque anti- 
purgado. Desgraciadamente, existe una tendencia a 
incorporar la manipulación de errores en el software 
y asíno probarlo nunca. Como ejemplo, sirve una his- 
toria real: 

Mediante un contrato se desarrolló un importante sistema 
de diseñointeractivo.En un módulo de proceso de transaccio- 
nes, un bromista puso el siguientemensaje de manipulación de 
error que aparecía tras una serie de pruebas condicionales que 
invocaban variasramificaciones del flujo de control: ¡ERROR! 
NO HAY FORMA DE QUE VD. LLEGUE HASTA AQUI. 


¡Este «mensaje de error» fue descubiertopor un clienteduran- 
te la fase de puesta a punto! 


Conse) 


Asegura que tu diseño de pruebas ejecuta todos los caminos 
pura encontrarerrores. Sino lo haces, el camino puede fallar 
al ser invocado, provocando una situación incierta. 


Entre los errores potenciales que se deben compro- 
bar cuando se evalúa la manipulación de errores están: 


1. Descripción ininteligible del error. 


2. El error señalado no se corresponde con el error 
encontrado. 


3, 


La condición de error hace que intervenga el sistema 
antes que el mecanismo de manejo de errores. 

. El procesamiento de la condición excepcional es 
incorrecto. 


. La descripción del error no proporciona suficiente 
información para ayudar en la localización de la 
causa del error. 


La prueba de límites es la última (y probablemente, 
la más importante) tarea del paso de la prueba de uni- 
dad. El software falla frecuentemente en sus condicio- 
nes límite. Es decir, con frecuencia aparece un error 
cuando se procesa el elemento n-ésimo de un array n- 
dimensional, cuando se hace la i-ésima repetición de un 
bucle de i pasos o cuando se encuentran los valores 
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máximo o mínimo permitidos. Los casos de prueba que 
ejerciten las estructuras de datos, el flujo de control y 
los valores de los datos por debajo y por encima de los 
máximos y los mínimos son muy apropiados para des- 
cubrir estos errores. 


Interfaz 


Prntanladao 


Estructuras de datos locales 
Condiciones límite 

Caminos independientes 
Módulo 


que se 
va a probar 


Caminos de manejo de ertores 


Casos 
de prueba 


RESULTADOS 


FIGURA 18.5. Entorno para la prueba de unidad. 


18.3.2. Procedimientos de Prueba de Unidad 


Debido a que un componente no es un programa inde- 
pendiente, se debe desarrollar para cada prueba de uni- 
dad un softwareque controle y/o resguarde. En la Figura 
18.5 se ilustra el entorno para la prueba de unidad. En 
la mayoría de las aplicaciones, un controladorno es más 
que un «programa principal» que acepta los datos del 
caso de prueba, pasa estos datos al módulo (a ser pro- 
bado) e imprime los resultados importantes. Los res- 
guardos sirven para reemplazar módulos que están 
subordinados (llamados por) el componente que hay 
que probar. Un resguardo o un «subprograma simula- 
do» usa la interfaz del módulo subordinado, lleva a cabo 
una mínima manipulación de datos, imprime una veri- 
ficación de entrada y devuelve control al módulo de 
prueba que lo invocó. 


Consuo fp 


Hay ocasiones en que no dispones de los recursos para hacer 
una prueba unitaria completa. En estasituación, selecciona 
los módulos críticos y aquellos con alta complejidad 
ciclomática y realiza sobre ellos la prueba unitaria. 


Los controladores y los resguardos son una sobre- 
carga de trabajo. Es decir, ambos son software que debe 
desarrollarse (normalmente no se aplica un diseño for- 
mal) pero que no se entrega con el producto de soft- 
ware final. Si los controladores y resguardos son 
sencillos, el trabajo adicional es relativamente peque- 
ño. Desgraciadamente, muchos componentes no pue- 
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den tener una adecuada prueba unitaria con un «senci- 
llo» software adicional. En tales casos, la prueba com- 
pleta se pospone hasta que se llegue al paso de prueba 
de integración (donde también se usan controladores o 
resguardos). 


La prueba de unidad se simplifica cuando se diseña 
un módulo con un alto grado de cohesión. Cuando un 
módulo sólo realiza una función, se reduce el número 
de casos de prueba y los errores se pueden predecir y 
descubrir más fácilmente. 


Un neófito del mundo del software podría, una vez que 
se les ha hecho la prueba de unidad a todos los módu- 
los, cuestionar de forma aparentemente legítima lo 
siguiente: «Si todos funcionan bien por separado, ¿por 
qué dudar de que funcionen todos juntos?» Por supues- 
to, el problema es «ponerlos juntos» (Interacción). Los 
datos se pueden perder en una interfaz; un módulo pue- 
de tener un efecto adverso e inadvertido sobre otro; las 
subfunciones, cuando se combinan, pueden no produ- 
cir la función principal deseada; la imprecisión acep- 
tada individualmente puede crecer hasta niveles 
inaceptables; y las estructuras de datos globales pue- 
den presentar problemas. Desgraciadamente, la lista 
sigue y sigue. 

La prueba de integración es una técnica sistemática 
para construir la estructura del programa mientras que, 
al mismo tiempo, se llevan a cabo pruebas para detec- 
tar errores asociados con la interacción. El objetivo es 
coger los módulos probados mediante la prueba de uni- 
dad y construir una estructura de programa que esté de 
acuerdo con lo que dicta el diseño. 


onsiof) 


Efectuar una integración big bag es una estrategia vaga 
que está condenada al fracaso. la prueba de integración 
deberú ser conducida incrementalmente. 


A menudo hay una tendencia a intentar una integra- 
ción no incremental; es decir, a construir el programa 
mediante un enfoque de «big bang». Se combinan todos 
los módulos por anticipado. Se prueba todo el progra- 
ma en conjunto. ¡Normalmente se llega al caos! Se 
encuentran un gran conjunto de errores. La corrección 
se hace difícil, puesto que es complicado aislar las cau- 
sas al tener delante el programa entero en toda su exten- 
sión. Una vez que se corrigen esos errores aparecen otros 
nuevos y el proceso continúa en lo que parece ser un 
ciclo sin fin. 

La integración incremental es la antítesis del enfo- 
que del «big bang». El programa se construye y se prue- 
ba en pequeños segmentos en los que los errores son 
más fáciles de aislar y de corregir, es más probable que 


3 Las estrategias de integración para sistemas orientados a objetos 
se tratan en el Capitulo 23. 
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se puedan probar completamente las interfaces y se pue- 
de aplicar un enfoque de prueba sistemática. En las 
siguientes secciones se tratan varias estrategias de inte- 
gración incremental diferentes. 


18.4.1. Integración descendente 


La prueba de integración descendente es un plantea- 
miento incremental a la construcción de la estructura de 
programas. Se integran los módulos moviéndose hacia 
abajo por la jerarquía de control, comenzando por el 
módulo de control principal (programa principal). Los 
módulos subordinados (subordinados de cualquier 
modo) al módulo de control principal se van incorpo- 
rando en la estructura, bien de forma primero-en-pro- 
fundidad, o bien de forma primero-en-anchura. 


Ronsuof) 


Cuando-desorrollas una planificación detallada del 
proyecto debes considerar la manera en que la 
integración se va a realizar, de forma quelos 
componentesestén disponiblescuando se necesiten. 


Como se muestra en la Figura 18.6, la integración pri- 
mero-en-profundidad integra todos los módulos de un 
camino de control principal de la estructura. La selección 
del camino principal es, de alguna manera, arbitraria y 
dependerá de las características específicas de la aplica- 
ción. Por ejemplo, si se elige el camino de la izquierda, 
se integrarán primero los módulos M1, M2 y M5.A con- 
tinuación, se integrará M8 o M6 (si es necesario para un 
funcionamientoadecuado de M2). Acto seguido se cons- 
truyen los caminos de control central y derecho. La inte- 
gración primero-en-anchura incorpora todos los módulos 
directamentesubordinadosa cada nivel, moviéndose por 
la estructura de forma horizontal. Según la figura, los pri- 
meros módulos que se integran son M2, M3 y M4.A con- 
tinuación, sigueel siguientenivel de control, M5, M6, etc. 


¿ Cuáles son los pasos para una 
integración top-down? 


El proceso de integración se realiza en una serie de 
cinco pasos: 
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. Se usa el módulo de control principal como contro- 
lador de la prueba, disponiendo de resguardos para 
todos los módulos directamente subordinados al 
módulo de control principal. 


Dependiendo del enfoque de integración elegido (es 
decir, primero-en-profundidad o primero-en-anchura) 
se van sustituyendo uno a uno los resguardos subor- 
dinados por los módulos reales. 


. Se llevan a cabo pruebas cada vez que se integra un 
nuevo módulo. 


. Tras terminar cada conjunto de pruebas, se reem- 
plaza otro resguardo con el módulo real. 


. Se hace la prueba de regresión (Sección 18.4.3) 
para asegurarse de que no se han introducido erro- 
res nuevos. 

El proceso continúa desde el paso 2 hasta que se haya 
construido la estructura del programa entero. 


FIGURA 18.6. Integración descendente, 


La estrategia de integración descendente verifica los 
puntos de decisión o de control principales al principio 
del proceso de prueba. En una estructura de programa bien 
fabricada, la toma de decisiones se da en los niveles supe- 
riores de lajerarquía y, por tanto, se encuentran antes. Si 
existen problemas generales de control, es esencial reco- 
nocerlos cuanto antes. Si se selecciona la integración pri- 
mero en profundidad, se puede ir implementando y 
demostrando las funciones completas del software. Por 
ejemplo, considere una estructura clásica de transacción 
(Capítulo 14) en la que se requiere una compleja serie de 
entradas interactivas, obtenidas y validadas por medio de 
un camino de entrada. Ese camino de entrada puede ser 
integradoen forma descendente. Así, se puede demostrar 
todo el proceso de entradas (para posteriores operaciones 
de transacción) antes de que se integren otros elementos 
de la estructura. La demostración anticipada de las posi- 
bilidades funcionales es un generador de confianza tanto 
para el desanollador como para el cliente. 


Referencia cruzada 


10 fabricación es importantepora ciertos estilos de 
arquitectura. Para más detalles ver el Capítulo 14.. 


La estrategia descendente parece relativamente fácil, 
pero, en la práctica, pueden surgir algunos problemas 
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logísticos. El más común de estos problemas se da cuan- 
do se requiere un proceso de los niveles más bajos de 
lajerarquía para poder probar adecuadamente los nive- 
les superiores. Al principio de la prueba descendente, 
los módulos de bajo nivel se reemplazan por resguar- 
dos; por tanto, no pueden fluir datos significativos hacia 
arriba por la estructura del programa. El responsable de 
la prueba tiene tres opciones: (1) retrasar muchas de las 
pruebas hasta que los resguardos seanreemplazados por 
los módulos reales; (2) desarrollar resguardos que rea- 
licen funciones limitadas que simulen los módulos rea- 
les; o (3) integrar el software desde el fondo de la 


jerarquía hacia arriba. 
Ed ¿Qué problemas puedes encontrar 
cuando elijas una estrategia 
de integración descendente? 


El primer enfoque (retrasar pruebas hasta reempla- 
zar los resguardos por los módulos reales) hace que per- 
damos cierto control sobre la correspondencia de ciertas 
pruebas específicas con la incorporación de determina- 
dos módulos. Esto puede dificultar la determinación de 
las causas del error y tiende a violar la naturaleza alta- 
mente restrictiva del enfoque descendente. El segundo 
enfoque es factible pero puede llevar a un significativo 
incremento del esfuerzo a medida que los resguardos se 
hagan más complejos. El tercer enfoque, denominado 
prueba ascendente, se estudia en la siguiente sección. 


18.4.2. Integraciónascendente 


La prueba de la integración ascendente, como su nom- 
bre indica, empieza la construcción y la prueba con los 
módulos atómicos (es decir, módulos de los niveles más 
bajos de la estructura del programa). Dado que los 
módulos se integran de abajo hacia arriba, el proceso 
requerido de los módulos subordinados siempre está 
disponible y se elimina la necesidad de resguardos. 


¿Cuáles son los pasos para 
una integraciónascendente? 


Se puede implementar una estrategia de integración 
ascendente mediante los siguientes pasos: 


1, Se combinan los módulos de bajo nivel en grupos (a 
veces denominadosconstrucciones) que realicen una 
subfunción específica del software. 

Se escribe un controlador (un programa de control 
de la prueba) para coordinar la entrada y la salida de 
los casos de prueba. 

Se prueba el grupo. 

Se eliminan los controladores y se combinan los gru- 
pos moviéndose hacia arriba por la estructura del 
programa. 


¡90 


La integración sigue el esquema ilustrado en la Figu- 
ra 18.7.Se combinanlos módulos para formar los gru- 
pos 1,2 y 3. Cada uno de los grupos se somete a prueba 
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mediante un controlador (mostrado como un bloque 
punteado). Los módulos de los grupos 1 y 2 son subor- 
dinados de M,. Los controladores D, y D, se eliminan 
y los grupos interaccionandirectamentecon M,. De for- 
ma similar, se elimina el controlador D, del grupo 3 
antes de la integración con el módulo M,. Tanto M, 
como M, se integrarán finalmente con el módulo M, y 
así sucesivamente. 


Y) 
Ss 

AVE 
l a integracón asco elimina la 
necesttd de resguardoscomplejos. 


A medida que la integración progresa hacia arriba, 
disminuye la necesidad de controladoresde prueba dife- 
rentes. De hecho, si los dos niveles superiores de la 
estructura del programa se integran de forma descen- 
dente, se puede reducir sustancialmente el número de 
controladores y se simplifica enormemente la integra- 
ción de grupos. 


18.4,3. Prueba de regresión 


Cada vez que se añade un nuevo módulo como parte de 
una prueba de integración, el software cambia. Se esta- 
blecen nuevos caminos de flujo de datos, pueden ocu- 
rrir nuevas E/S y se invoca una nueva lógica de control. 
Estos cambios pueden causar problemas con funciones 
que antes trabajaban perfectamente. En el contexto de 
una estrategia de prueba de integración, la prueba de 
regresión es volver a ejecutar un subconjunto de prue- 
bas que se han llevado a cabo anteriormente para ase- 
gurarse de que los cambios no han propagado efectos 
colaterales no deseados. 


35 E dE Grupo 3 


Grupo 2 


Grupo 1 


FIGURA 18.7. Integración ascendente. 


En un contexto más amplio, las pruebas con éxito 
(de cualquier tipo) dan comoresultado el descubrimiento 
de errores, y los errores hay que corregirlos. Cuando se 
corrige el software, se cambia algún aspecto de la con- 
figuración del software (el programa, su documentación 
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O los datos que lo soportan). La prueba de regresión es 
la actividad que ayuda a asegurar que los cambios (debi- 
dos a las pruebas o por otros motivos) no introducen un 
comportamiento no deseado o errores adicionales. 


lor 


la prueba de regresión es una estrategia importantepara 
reducir «efectos colaterales». Se debenejecutar pruebas 
de regresión cada vezque se realice un cambio 
importanteen el software (incluyendola integración de 
nuevos módulos). 


La prueba de regresión se puede hacer manualmen- 
te, volviendo a realizar un subconjunto de todos los 
casos de prueba o utilizando herramientas automáticas 
de reproducción de captura. Las herramientas de repro- 
ducción de captura permiten al ingeniero del softwa- 
re capturar casos de prueba y los resultados para la 
subsiguiente reproducción y comparación. El conjun- 
to de pruebas de regresión (el subconjunto de pruebas 
a realizar) contiene tres clases diferentes de casos de 
prueba: 


una muestra representativa de pruebas que ejercite 
todas las funciones del software; 


pruebas adicionales que se centran en las funciones 
del software que se van a ver probablemente afecta- 
das por el cambio; 


pruebas que se centran en los componentes del soft- 
ware que han cambiado. 

A medida que progresa la prueba de integración, el 
número de pruebas de regresión puede crecer demasia- 
do. Por tanto, el conjunto de pruebas de regresión debe- 
ría diseñarse para incluir sólo aquellaspruebas que traten 
una o más clases de errores en cada una de las funcio- 
nes principales del programa. No es práctico ni eficiente 
volver a ejecutar cada prueba de cada función del pro- 
grama después de un cambio. 


18.4.4. Prueba de humo 


La prueba de humo es un método de prueba de inte- 
gración que es comúnmente utilizada cuando se ha 
desarrollado un producto software «empaquetado». 
Es diseñado como un mecanismo para proyectos crí- 
ticos por tiempo, permitiendo que el equipo de soft- 
ware valore su proyecto sobre una base sólida. En 
esencia, la prueba de humo comprende las siguientes 
actividades: 


1. Los componentes software que han sido traducidos 
a código se integran en una «construcción», Una 
construcción incluye ficheros de datos, librerías, 
módulos reutilizables y componentes de ingeniería 
que se requieren para implementar una o más fun- 
ciones del producto. 


Se diseña una serie de pruebas para descrubir erro- 
res que impiden a la construcción realizar su fun- 
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ción adecuadamente. El objetivo será descubrir erro- 
res «bloqueantes» que tengan la mayor probabili- 
dad de impedir al proyecto de software el 
cumplimiento de su planificación. 


3, Es habitual en la prueba de humo que la construcción 
se integre con otras construcciones y que se aplica una 
prueba de humo al producto completo (en su forma 
actual). La integración puede hacerse bien de forma 
descendente (top-down)o ascendente (bottom-up). 


» 
e 
EY VE 


la prueba de humo se caracteriza por una estrategia de integración 
continua. El software es reconfigurado (con la incorporaciónde 
nuevos componentes) y utilizado continuamente. 


La frecuencia continua de la prueba completa del 
producto puede sorprender a algunos lectores. En cual- 
quier caso, las frecuentes pruebas dan a gestores y pro- 
fesionales una valoración realista de la evolución de las 
pruebas de integración. McConnell [MCO96] describe 
la prueba de humo de la siguiente forma: 


La prueba de humo ejercita el sistema entero de prin- 
cipio a fin. No ha de ser exhaustiva, pero será capaz de 
descubrir importantes problemas. La prueba de humo será 
suficiente si verificamos de forma completa la construc- 
ción y podemos asumir que es suficientemente estable para 
ser probado con más profundidad. 


La prueba de humo facilita una serie de beneficios 
cuando se aplica sobre proyectos de ingeniería del soft- 
ware complejos y críticos por su duración: 


.* Seminimizan los riesgos de integración. Dado que 
las pruebas de humo son realizadas frecuentemente, 
incompatibilidades y otros errores bloqueantes son 
descubiertos rápidamente, por eso se reduce la posi- 
bilidad de impactos importantes en la planificación 
por errores sin descubrir. 


Se perfecciona la calidad del producto final. Dado 
que la prueba de humo es un método orientado a la 
construcción (integración), es probable que descu- 
bra errores funcionales, además de defectos de diseño 
a nivel de componente y de arquitectura. Si estos 
defectos se corrigen rápidamente, el resultado será 
un producto de gran calidad. 


yes el oliciente del proyecto. 
el proyecto se muere. 


. Sesimplifican el diagnóstico y la corrección de erro- 
res. Al igual que todos los enfoques de prueba de 
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integración, es probable que los errores sin descu- 
brir durante la prueba de humo se asocien a«nuevos 
incrementos de software» - es toes, el software que 
se acaba de añadir a la construcción es una posible 
causa de un error que se acaba de descubrir—. 


El progreso esfácil de observar. Cada día que pasa, 
se integra más software y se demuestra que fun- 
ciona. Esto mejora la moral del equipo y da una 
indicación a los gestores del progreso que se está 
realizando. 


18.4.5. Comentarios sobre la prueba de inte- 
gración 

Ha habido muchos estudios (por ejemplo, [BEI84]) 
sobre las ventajas y desventajas de la prueba de inte- 
gración ascendente frente a la descendente. En gene- 
ral, las ventajas de una estrategia tienden a convertirse 
en desventajas para la otra estrategia. La principal des- 
ventaja del enfoque descendente es la necesidad de 
resguardos y las dificultades de prueba que pueden 
estar asociados con ellos. Los problemas asociados 
con los resguardos pueden quedar compensados por 
la ventaja de poder probar de antemano las principa- 
les funciones de control. La principal desventaja de la 
integración ascendente es que «el programa como enti- 
dad no existe hasta que se ha añadido el último módu- 
lo» [MYE79]. Este inconveniente se resuelve con la 
mayor facilidad de diseño de casos de prueba y con la 
falta de resguardos. 


La selección de una estrategia de integración 
depende de las características del software y, a veces, 
de la planificación del proyecto. En general, el mejor 
compromiso puede ser un enfoque combinado (a veces 
denominado prueba sandwich) que use la descendente 
para los niveles superiores de la estructura del pro- 
grama, junto con la ascendente para los niveles subor- 
dinados. 


A medida que progresa la prueba de integración, 
el responsable de las pruebas debe identificar los 
módulos críticos. Un módulo crítico es aquel que tie- 
ne una O más de las siguientes características: (1) está 
dirigido a varios requisitos del software; (2) tiene un 
mayor nivel de control (está relativamente alto en la 
estructura del programa); (3) es complejo o propen- 
so a errores (se puede usar la complejidad ciclomáti- 
ca como indicador); o (4)tiene unos requisitos de 
rendimiento muy definidos. Los módulos críticos 
deben probarse lo antes posible. Además, las pruebas 
de regresión se deben centrar en el funcionamiento de 
los módulos críticos. 


¿Qué es un módulo crítico y 
por qué debemos identificarlo? 
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Tras la culminación de la prueba de integración, el soft- 
ware está completamente ensamblado como un paque- 
te, se han encontrado y corregido los errores de interfaz 
y puede comenzar una serie final de pruebas del soft- 
ware: la prueba de validación. La validación puede defi- 
nirse de muchas formas, pero una simple (aunque vulgar) 
definición es que la validación se consigue cuando el 
software funciona de acuerdo con las expectativas razo- 
nables del cliente. En este punto, un desarrollador de 
software estricto podría protestar: «¿Qué o quién es el 
árbitro de las expectativas razonables?» 


a 
j CLA VE 


Como en otras etapas de la prueba, la validación permite 
descubrir errores, pero su enfoque está en el nivel de 
requisitos —sobre cosas que son necesariaspara el 
usuario final —. 


Las expectativas razonables están definidas en la 
Especificación de Requisitos del Software —un docu- 
mento (Capítulo 12)que describe todos los atributos del 
software visibles para el usuario. La especificacióncon- 
tiene una sección denominada —. «Criterios de valida- 
ción». La información contenida en esa sección forma 
la base del enfoque a la prueba de validación. 


18.5.1. Criterios de la prueba de validación 


La validación del software se consigue mediante una 
serie de pruebas de caja negra que demuestran la con- 
formidad con los requisitos. Un plan de prueba traza 
la clase de pruebas que se han de llevar a cabo, y un 
procedimiento de prueba define los casos de prueba 
específicos en un intento por descubrir errores de 
acuerdo con los requisitos. Tanto el plan como el pro- 
cedimiento estarán diseñados para asegurar que se 
satisfacen todos los requisitos funcionales, que se 
alcanzan todos los requisitos de rendimiento, que la 
documentaciónes correcta e inteligible y que se alcan- 
zan otros requisitos (por ejemplo, portabilidad, com- 
patibilidad, recuperación de errores, facilidad de 
mantenimiento). 

Una vez que se procede con cada caso de prueba de 
validación, puede darse una de las dos condiciones 
siguientes: (1) las características de funcionamiento o 
de rendimiento están de acuerdo con las especificacio- 
nes y son aceptables; o (2)'se descubre una desviación 
de las especificaciones y se crea una lista de deficien- 
cias. Las desviaciones o errores descubiertos en esta 
fase del proyecto raramente se pueden corregir antes 
de la terminación planificada. A menudo es necesario 
negociar con el cliente un método para resolver las defi- 
ciencias. 
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18.5.2. Revisión de la configuración 


Un elemento importante del proceso de validaciónes la 
revisión de la configuración. La intención de la revisión 
es asegurarse de que todos los elementos de la confi- 
guración del software se han desarrollado apropiada- 
mente, se han catalogado y están suficientemente 
detallados para soportar la fase de mantenimiento duran- 
te el ciclo de vida del software. La revisión de la confi- 
guración, a veces denominada auditoría, se ha estudiado 
con más detalle en el Capítulo 9. 


18.5.3. Pruebas alfa y beta 


Es virtualmente imposible que un desarrollador de soft- 
ware pueda prever cómo utilizará el usuario realmente 
el programa. Se pueden malinterpretar las instruccio- 
nes de uso, se pueden utilizar habitualmente extrañas 
combinaciones de datos, y una salida que puede pare- 
cer clara para el responsable de las pruebas y puede ser 
ininteligible para el usuario. 

Cuando se construye software a medida para un clien- 
te, se llevan a cabo una serie de pruebas de aceptación 
para permitir que el cliente valide todos los requisitos. 
Las realiza el usuario final en lugar del responsable del 
desarrollo del sistema, una prueba de aceptación puede 
1r desde un informal «paso de prueba» hasta la ejecución 
sistemática de una serie de pruebas bien planificadas. De 
hecho, la prueba de aceptación puede tener lugar a lo 
largo de semanas O meses, descubriendo así errores acu- 
mulados que pueden ir degradando el sistema. 

Si el software se desarrolla como un producto que 
va a ser usado por muchos clientes, no es práctico rea- 
lizar pruebas de aceptación formales para cada uno de 
ellos. La mayoría de los desarrolladores de productos 
de software llevan a cabo un proceso denominado prue- 
ba alfa y beta para descubrir errores que parezca que 
sólo el usuario final puede descubrir. 

La prueba alfa se lleva a cabo, por un cliente, en el 
lugar de desarrollo. Se usa el software de forma natu- 
ral con el desarrollador como observador del usuario y 
registrando los errores y los problemas de uso. Las prue- 
bas alfa se llevan a cabo en un entorno controlado. 

La prueba beta se lleva a cabo por los usuarios fina- 
les del software en los lugares de trabajo de los clien- 
tes. A diferencia de la prueba alfa, el desarrollador no 
está presente normalmente. Así, la prueba beta es una 
aplicación «en vivo» del software en un entorno que no 
puede ser controlado por el desarrollador. El cliente 
registra todos los problemas (reales o imaginarios) que 
encuentra durante la prueba beta e informa a intervalos 
regulares al desarrollador. Como resultado de los pro- 
blemas informados durante la prueba beta, el desarro- 
llador del software lleva a cabo modificaciones y así 
prepara una versión del producto de software para toda 
la clase de clientes. 
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Al comienzo de este libro, pusimos énfasis en el hecho 
de que el software es sólo un elemento de un sistema 
mayor basado en computadora. Finalmente, el softwa- 
re es incorporado a otros elementos del sistema (por 
ejemplo, nuevo hardware, información) y realizan una 
serie de pruebas de integración del sistema y de vali- 
dación. Estas pruebas caen fuera del ámbito del proce- 
so de ingeniería del software y no las realiza únicamente 
el desarrollador del software. Sin embargo, los pasos 
dados durante el diseño del software y durante la prue- 
ba pueden mejorar enormemente la probabilidad de éxi- 
to en la integración del software en el sistema. 


Un problema típico de la prueba del sistema es la 
((delegaciónde culpabilidad». Esto ocurre cuando se 
descubre un error y cada uno de los creadores de cada 
elemento del sistema echa la culpa del problema a los 
otros. En vez de verse envuelto en esta absurda situa- 
ción, el ingeniero del software debe anticiparse a los 
posibles problemas de interacción y: (1) diseñar cami- 
nos de manejo de errores que prueben toda la infor- 
mación procedente de otros elementos del sistema; (2) 
llevar a cabo una serie de pruebas que simulen la pre- 
sencia de datos en mal estado o de otros posibles erro- 
res en la interfaz del software; (3) registrar los 
resultados de las pruebas como «evidencia» en el caso 
de que se le señale con el dedo; (4) participar en la pla- 
nificación y el diseño de pruebas del sistema para ase- 
gurarse de que el software se prueba de forma 
adecuada. 

La prueba del sistema, realmente, está constituida 
por una serie de pruebas diferentes cuyo propósito pri- 
mordial es ejercitar profundamente el sistema basado 
en computadora. Aunque cada prueba tiene un propó- 
sito diferente, todas trabajan para verificar que se han 
integrado adecuadamente todos los elementos del sis- 
tema y que realizan las funciones apropiadas. En las 
siguientes secciones examinamos los tipos de pruebas 
del sistema [BEI84] valiosos para sistemas basados en 
software. 


18.6.1, Prueba de recuperación 


Muchos sistemas basados en computadora deben recu- 
perarse de los fallos y continuar el proceso en un tiem- 
po previamente especificado. En algunos casos, un 
sistema debe ser tolerante con los fallos; es decir, los 
fallos del proceso no deben hacer que cese el funcio- 
namiento de todo el sistema. 
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Amplia información sobre la prueba del software y su 
relación con las necesidadesde calidad pueden obtenerse 
en www.stqe.net 


En otros casos, se debe corregir un fallo del sistema 
en un determinado periodo de tiempo para que no se 
produzca un serio daño económico. 

La prueba de recuperación es una prueba del siste- 
ma que fuerza el fallo del software de muchas formas 
y verifica que la recuperación se lleva a cabo apropia- 
damente. Si la recuperación es automática (llevada a 
cabo por el propio sistema) hay'que evaluar la correc- 
ción de la inicialización, de los mecanismos de recupe- 
ración del estado del sistema, de la recuperación de datos 
y del proceso de rearranque. Si la recuperación requie- 
re la intervención humana, hay que evaluar los tiempos 
medios de reparación (IMR) para determinar si están 
dentro de unos límites aceptables. 


18.6.2. Prueba de seguridad 


Cualquier sistema basado en computadora que maneje 
información sensible o lleve a cabo acciones que pue- 
dan perjudicar (o beneficiar) impropiamente a las per- 
sonas es un posible objetivo para entradas impropias O 
ilegales al sistema. Este acceso al sistema incluye un 
amplio rango de actividades: «piratas informáticos» 
que intentan entrar en los sistemas por deporte, emplea- 
dos disgustados que intentan penetrar por venganza e 
individuos deshonestos que intentan penetrar para obte- 
ner ganancias personales ilícitas. 

La prueba de seguridad intenta verificar que los 
mecanismos de protección incorporados en el sistema 
lo protegerán, de hecho, de accesos impropios. Para citar 
a Beizer [BEI84]: «Por supuesto, la seguridad del sis- 
tema debe ser probada en su invulnerabilidad frente a 
un ataque frontal, pero también debe probarse en su 
invulnerabilidad a ataques por los flancos o por la reta- 
guardia.» 

Durante la prueba de seguridad, el responsable de la 
prueba desempeña el papel de un individuo que desea 
entrar en el sistema. ¡Todo vale! Debe intentar conse- 
guir las claves de acceso por cualquier medio, puede 
atacar al sistema con software a medida, diseñado para 
romper cualquier defensa que se haya construido, debe 
bloquear el sistema, negando así el servicio a otras per- 
sonas, debe producir a propósito errores del sistema, 
intentando acceder durante la recuperación o debe curio- 
searen los datos sin protección, intentando encontrar la 
clave de acceso al sistema, etc. 

Con tiempo y recursos suficientes, una buena prue- 
ba de seguridad terminará por acceder al sistema. El 
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papel del diseñador del sistema es hacer que el coste de 
la entrada ilegal sea mayor que el valor de la informa- 
ción obtenida. 


ontror verdaderamente fallos en 
has sometido tu software a una 
nia, entonces has perdido 


18.6.3. Prueba de resistencia (Stress) 


Durante los pasos de prueba anteriores, las técnicas de 
caja blanca y de caja negra daban comoresultado la eva- 
luación del funcionamiento y del rendimiento norma- 
les del programa. Las pruebas de resistencia están 
diseñadas para enfrentar a los programas con situacio- 
nes anormales. En esencia, el sujeto que realiza la prue- 
ba de resistencia se pregunta: «¿A qué potencia puedo 
ponerlo a funcionar antes de que falle?» 

Laprueba de resistencia ejecuta un sistema de for- 
ma que demande recursos en cantidad, frecuencia o 
volúmenes anormales. Por ejemplo: (1) diseñar prue- 
bas especiales que generen diez interrupciones por 
segundo, cuando las normales son una o dos; (2) incre- 
mentar las frecuencias de datos de entrada en un orden 
de magnitud con el fin de comprobar cómo respon- 
den las funciones de entrada; (3 )ejecutar casos de 
prueba que requieran el máximo de memoria o de 
otros recursos; (4)diseñar casos de prueba que pue- 
dan dar problemas en un sistema operativo virtual o 
(5 )diseñar casos de prueba que produzcan excesivas 
búsquedas de datos residentes en disco. Esencial- 
mente, el responsable de la prueba intenta romper el 
programa. 

Una variante de la prueba de resistencia es una téc- 
nica denominada prueba de sensibilidad. En algunas 


situaciones (la más común se da con algoritmos mate- 
máticos), un rango de datos muy pequeño dentro de 
los límites de una entrada válida para un programa pue- 
de producir un proceso exagerado e incluso erróneo o 
una profunda degradación del rendimiento. Esta situa- 
ción es análoga a una singularidad en una función 
matemática. La prueba de sensibilidad intenta descu- 
brir combinaciones de datos dentro de una clase de 
entrada válida que pueda producir inestabilidad o un 
proceso incorrecto. 


18.6.4. Prueba de rendimiento 


Para sistemas de tiempo real y sistemas empotrados, 
es inaceptable el software que proporciona las fun- 
ciones requeridas pero no se ajusta a los requisitos de 
rendimiento. La prueba de rendimiento está diseñada 
para probar el rendimiento del software en tiempo de 
ejecución dentro del contexto de un sistema integra- 
do. La prueba de rendimiento se da durante todos los 
pasos del proceso de la prueba. Incluso al nivel de uni- 
dad, se debe asegurar el rendimiento de los módulos 
individuales a medida que se llevan a cabo las prue- 
bas de caja blanca. Sin embargo, hasta que no están 
completamente integrados todos los elementos del sis- 
tema no se puede asegurar realmente el rendimiento 
del sistema. 

Las pruebas de rendimiento, a menudo, van empa- 
rejadas con las pruebas de resistencia y, frecuentemen- 
te, requieren instrumentación tanto de software como 
de hardware. Es decir, muchas veces es necesario medir 
la utilización de recursos (por ejemplo, ciclos de pro- 
cesador), de un modo exacto. La instrumentaciónexter- 
na puede monitorizar los intervalos de ejecución, los 
sucesos ocurridos (por ejemplo, interrupciones)y mues- 
tras de los estados de la máquina en un funcionamien- 
to normal. Instrumentando un sistema, el encargadode 
la prueba puede descubrir situaciones que lleven a degra- 
daciones y posibles fallos del sistema. 


La prueba del software es un proceso que puede plani- 
ficarse y especificarse sistemáticamente. Se puede lle- 
var a cabo el diseño de casos de prueba, se puede definir 
una estrategia y se pueden evaluar los resultados en com- 
paración con las expectativas prescritas. 

La depuración ocurre como consecuencia de una 
prueba efectiva. Es decir, cuando un caso de prueba des- 
cubre un error, la depuración es el proceso que provo- 
ca la eliminación del error. Aunque la depuración puede 
y debe ser un proceso ordenado, sigue teniendo mucho 
de arte. Un ingeniero del software, al evaluar los resul- 
tados de una prueba, se encuentra frecuentemente con 
una indicación«sintomática» de un problema en el soft- 
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ware. Es decir, la manifestación externa de un error, y 
la causa interna del error pueden no estar relacionados 
de una forma obvia. El proceso mental, apenas com- 
prendido, que conecta un síntoma con una causa es la 
depuración. 


Referencia 


BugNet facilita información sobre problemasde seguridad 
y fallos en sofwore basado en PC y proporcionauna 
información Útil sobre temas de depuración: 
www.bugnet.com 
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18.7.1. El Proceso de depuración 


La depuración no es una prueba, pero siempre ocurre 
como consecuencia de la prueba”, Como se muestra en 
la Figura 18.8,el proceso de depuración comienza con 
la ejecución de un caso de prueba. Se evalúan los resul- 
tados y aparece una falta de correspondencia entre los 
esperados y los encontradosrealmente. En muchos casos, 
los datos que no concuerdan son un síntoma de una cau- 
sa subyacente que todavía permanece oculta. El proce- 
so de depuración intenta hacer corresponder el sistema 
con una causa, llevando así a la corrección del error. 

El proceso de depuración siempre tiene uno de los 
dos resultados siguientes: (1) se encuentra la causa, se 
corrige y se elimina; o (2) no se encuentra la causa. En 
este último caso, la persona que realiza la depuración 
debe sospechar la causa, diseñar un caso de prueba que 
ayude a confirmar sus sospechas y el trabajo vuelve hacia 
atrás a la corrección del error de una forma iterativa. 

¿Por qué es tan difícil la depuración? Todo parece 
indicar que la respuesta tiene más que ver con la psico- 
logía humana (véase la siguiente sección) que con la 
tecnología del software. Sin embargo, varias caracte- 
rísticas de los errores nos dan algunas pistas: 


1. El síntoma y la causa pueden ser geográficamente 
remotos entre sí. Es decir, el síntoma puede apare- 
cer en una parte del programa, mientras que la causa 
está localizada en otra parte muy alejada. Las estruc- 
turas de programa fuertemente acopladas (Capítulo 
13) resaltan esta situación. 

El síntoma puede desaparecer (temporalmente) al 
corregir otro error. 


» 


3. El síntoma puede realmente estar producido por algo 
que no es un error (por ejemplo, inexactitud en los 
redondeos). 


4. El síntoma puede estar causado por un error humano 
que no sea fácilmente detectado. 


a 


El síntoma puede ser el resultado de problemas de 
temporización en vez de problemas de proceso. 


A 


Puede ser difícil reproducir exactamente las condi- 
ciones de entrada (por ejemplo, una aplicación de 
tiempo real en la que el orden de la entrada no está 
determinado). 


entro de los programas de computador 
[pora depuración] es probablemente 

lod en otros ejemplos de sistemas 

te diognosficados. 


4 Al decir esta frase, tomamos el punto de vista más amplio que se 
puede tener de la prueba. No sólo ha de llevar a cabo la prueba el 
equipo de desarrollo antes de entregar el software, sino que el 
cliente/usuario prueba el software cada vez que lo usa. 
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7. El síntoma puede aparecer de forma intermitente. 
Esto es particularmente comente en sistemas empo- 
trados que acoplan el hardware y el software de 
manera confusa. 


8. El síntoma puede ser debido a causas que se distri- 
buyen por una serie de tareas ejecutándose en dife- 
rentes procesadores [CHE90)]. 


Durante la depuración encontramos errores que van 
desde lo ligeramente inesperado (por ejemplo, un for- 
mato de salida incorrecto) hasta lo catastrófico (por 
ejemplo, el sistema falla, produciéndose serios daños 
económicos o físicos). A medida que las consecuencias 
de un error aumentan, crece la presión por encontrar su 
causa. A menudo la presión fuerza a un ingeniero del 
software a corregir un error introduciendo dos más. 


Ejecución de casos 


— Pruebas 
adicionales — 
X Pruebas pos 
de regresion sospechada 
recon 
orrecciongs Causas 


Identificadas 


FIGURA 18.8. El proceso de depuración. 


18.7.2, Consideraciones psicológicas 


Desafortunadamente, todo parece indicar que la habili- 
dad en la depuración es un rasgo innato del ser huma- 
no. A ciertaspersonas se les da bien y a otrasno. Aunque 
las manifestaciones experimentales de la depuración 
están abiertas a muchas interpretaciones, se han detec- 
tado grandes variaciones en la destreza para la depura- 
ción de distintos programadores con el mismo bagaje 
de formación y de experiencia. 


Hablando de los aspectos humanos de la depuración, 
Shneiderman [SHN80] manifiesta: 


La depuración es una de las partes más frustrantes de la pro- 
gramación. Contiene elementos de resolución de problemas o 
de rompecabezas, junto con el desagradable reconocimiento de 
que se ha cometido un error. La enorme ansiedad y la no incli- 
nación a aceptar la posibilidad de cometer errores hace que la 
tarea sea extremadamente difícil. Afortunadamente, también se 
da un gran alivio y disminuye la tensión cuando el error es final- 
mente...corregido. 


Aunque puede resultar difícil «aprender» a depurar, 
se pueden proponer varios enfoques del problema. En 
la siguiente sección los examinamos. 
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18.73, Enfoques de la depuración 


Independientemente del enfoque que se utilice, la depu- 
ración tiene un objetivo primordial: encontrar y corre- 
gir la causa de un error en el software. El objetivo se 
consigue mediante una combinación de una evaluación 
sistemática, de intuición y de suerte. Bradley [BRA85] 
describe el enfoque de la depuración de la siguiente 
forma: 

La depuración es una aplicación directa del método cientí- 
fico desarrollado hace 2.500 años. La base de la depuración es 
la localización de la fuente del problema [la causa] mediante 
partición binaria, manejando hipótesis que predigan nuevos 
valores a examinar. 

Tomemos un sencillo ejemplo que no tiene que ver con el 
software: en mi casa no funciona una lámpara. Si no funciona 
nada en la casa, la causa debe estar en el circuito principal de 
fusibles o fuera de la casa; miro fuera para ver si hay un apa- 
gón en todo el vecindario.Conecto la sospechosalámpara a un 
enchufe que funcione y un aparato que funcione en el circuito 
sospechoso.Así se siguela secuencia de hipótesis y de pruebas. 


En general, existen tres enfoques que se pueden pro- 
poner para la depuración [MYE79]: 


1. Fuerza bruta 
2. Vuelta atrás 
3. Eliminación de causas 


La categoría de depuración por la fuerza bruta es 
probablemente la más común y menos eficiente a la hora 
de aislar la causa del error en el software. Aplicamos 
los métodos de depuración por fuerza bruta cuando todo 
lo demás falla. Mediante una filosofía de «dejar que la 
computadora encuentre el error», se hacen volcados de 
memoria, trazas de ejecución y se cargan multitud de 
sentencias Mostrar en el programa. Esperamos que en 
algún lugar de la gran cantidad de información genera- 
da encontremos alguna pista que nos lleve a la causa de 
un error. Aunque la gran cantidad de información pro- 
ducida nos puede llevar finalmente al éxito, lo más fre- 
cuente es que se desperdicie tiempo y esfuerzo. ¡Primero 
se debe usar la inteligencia! 


Consucf) 


fíjate un tiempo limitado, por ejemplo dos horas, 
en relación a la cantidad de tiempo que tu inviertes 
para depurar un problema de tu incumbencia. 
Después qué, ¡pide ayuda! 


La vuelta atrás es un enfoque más normal para la 
depuración, que se puede usar con éxito para pequeños 
programas. Partiendo del lugar donde se descubre el sín- 
toma, se recorre hacia atrás (manualmente) el código 
fuente hasta que se llega a la posición de error. Des- 
graciadamente, a medida que aumenta el número de 
líneas del código, el número de posibles caminos de 
vuelta se hace difícilmente manejable. 

El tercer enfoque para la depuración —eliminación 
de causas — se manifiesta mediante inducción O deduc- 
ción e introduce el concepto de partición binaria. Los 
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datos relacionados con la ocurrencia del error se orga- 
nizan para aislar las posibles causas. Se llega a una 
«hipótesis de causa» y se usan los datos anteriores para 
probar orevocar la hipótesis. Alternativamente, se desa- 
rrolla una lista de todas las posibles causas y se llevan 
a cabo pruebas para eliminar cada una. Si alguna prue- 
ba inicial indica que determinada hipótesis de causa en 
particular parece prometedora, se refinan los datos con 
el fin de intentar aislar el error. 

Cada uno de los enfoques anteriores puede comple- 
mentarse con herramientas de depuración. Podemos usar 
una gran cantidad de compiladores de depuración, ayu- 
das dinámicas para la depuración («trazadores»), gene- 
radores automáticos de casos de prueba, volcados de 
memoria y mapas de referencias cruzadas. Sin embar- 
go, las herramientas no son un sustituto de la evalua- 
ción cuidadosa basada en un completo documento del 
diseño del software y un código fuente claro. 


Herramientas CASE 
Pruebo y Depuración. 


Cualquier discusión sobre los enfoques para la depu- 
ración y sus herramientas no estaría completa sin men- 
cionar un poderoso aliado: ¡otras personas! Cualquiera 
de nosotros podrá recordar haber estado dando vueltas 
en la cabeza durante horas o días a un error persisten- 
te. Desesperados, le explicamos el problema a un cole- 
ga con el que damos por casualidad y le mostramos el 
listado. Instantáneamente (parece), se descubre la cau- 
sa del error. Nuestro colega se aleja sonriendo ladina- 
mente. Un punto de vista fresco, no embotado por horas 
de frustración, puede hacer maravillas. Una máxima 
final para la depuración puede ser: «¡Cuando todo lo 
demás falle, pide ayuda!» 

Una vez que se ha encontrado un error, hay que corre- 
girlo. Pero como ya hemos podido observar, la correc- 
ción de un error puede introducir otros errores y hacer 
más mal que bien. 


Cuando corrijo un error, 
¿qué cuestiones debo 
preguntarmea mi mismo? 


Van Vleck [VAN89] sugiere tres preguntas sencillas 
que debería preguntarse todo ingeniero del software antes 
de hacer la «corrección» que elimine la causa del error: 
l ¿Se repite la causa del error en otra parte del pro- 

grama? En muchas situaciones, el defecto de un pro- 
grama está producido por un patrón de lógica erróneo 
que se puede repetir en cualquier lugar. La conside- 
ración explícita del patrón lógico puede terminar en 
el descubrimiento de otros errores. 
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2. ¿Cuál es el «siguiente error» que sepodrá presentara 
raíz de la corrección que hoy voy a realizar? Antes de 
hacer la corrección, se debe evaluarel código fuente (o 
mejor, el diseño) para determinarel emparejamientode 
la lógica y las estructuras de datos. Si la corrección se 
realiza en una sección del programa altamenteacoplada, 
se debe tener cuidado al realizar cualquier cambio. 


La prueba del software contabiliza el mayor porcenta- 
je del esfuerzo técnico del proceso de desarrollo de soft- 
ware. Todavía estamos comenzando a comprender las 
sutilezasde la planificación sistemática de la prueba, de 
su ejecución y de su control. 

El objetivo de la prueba de software es descubrir 
errores. Para conseguir este objetivo, se planifica y se 
ejecutan una serie de pasos; pruebas de unidad, de inte- 
gración, de validación y del sistema. Las pruebas de uni- 
dad y de integración se centran en la verificación 
funcional de cada módulo y en la incorporación de los 
módulos en una estructura de programa. La prueba de 
validación demuestra el seguimiento de los requisitos 
del software y la prueba del sistema valida el software 
una vez que se ha incorporado en un sistema superior. 

Cada paso de prueba se lleva a cabo mediante una 
serie de técnicas sistemáticas de prueba que ayudan en 
el diseño de casos de prueba. Con cada paso de prueba 
se amplía el nivel de abstracción con el que se consi- 
dera el software. 
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3. ¿Qué podríamos haber hecho para prevenir este 
error laprimera vez? Esta pregunta es el primer paso 
para establecer un método estadístico de garantía de 
calidad del software (Capítulo 8). Si corregimos tanto 
el proceso como el producto, se eliminará el error 
del programa actual y se puede eliminar de todos los 
futuros programas. 


A diferencia de la prueba (una actividad sistemática 
y planificada), la depuración se puede considerarun arte. 
A partir de una indicación sintomática de un problema, 
la actividad de la depuración debe rastrear la causa del 
error. De entre los recursos disponibles durante la depu- 
ración, el más valioso puede ser el apoyo de otros inge- 
nieros de software. 

El requisito de que el softwaresea cada vez de mayor 
calidad exige un planteamiento más sistemático de la 
prueba. Citando a Dunn y Ullman [DUN82]: 


Lo que se requiere es una estrategia global, que se extienda 
por el espacio estratégicode la prueba, tan deliberada en su meto- 
dología como lo fue el desarrollo sistemático en el que se basa- 
ron el análisis, el diseño y la codificación, 


En este capítulo hemos examinado el espacio estra- 
tégico de la prueba, considerando los pasos que tienen 
la mayor probabilidad de conseguir el fin Último de la 
prueba: encontrar y subsanar los defectos de una mane- 
ra ordenada y efectiva. 
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18.1. Con sus propias palabras, describa las diferencias entre 
verificación y validación. ¿Utilizan las dos los métodos de 
diseño de casos de prueba y las estrategias de prueba? 


18.2. Haga una lista de algunos problemas que puedan estar 
asociadoscon la creación de un grupo independiente de prue- 
ba. ¿Están formados por las mismas personas el GIP y el gru- 
po SQA? 


18.3. ¿Es siempre posible desarrollar una estrategia de prue- 
ba de software que use la secuencia de pasos de prueba des- 
crita en la Sección 18.1.3? ¿Qué posibles complicaciones 
pueden surgir para sistemas empotrados? 


18.4. Si sólo pudiera seleccionar tres métodos de diseño de 
casos de prueba para aplicarlos durante la prueba de unidad, 
¿cuáles serían y por qué? 


18.5. Porqué es difícil de realizar la prueba unitaria a un módu- 
lo con alto nivel de integración. 


18.6. Desarrolle una estrategia de prueba de integración para 
cualquiera de los sistemas implementados en los problemas 
16.4a 16.11. Defina las fases de prueba, indique el orden de 
integración, especifiqueel software de prueba adicional y jus- 


tifique el orden de integración. Suponga que todos los módu- 
los han sido probados en unidad y están disponibles.[Nota: 
puede ser necesario comenzar trabajando un poco con el dise- 
ño inicialmente.] 


18.7. ¿Cómo puede afectar la planificación del proyecto a la 
prueba de integración? 


18.8. ¿Es posible o incluso deseable la prueba de unidad en 
cualquier circunstancia? Ponga ejemplos que justifiquen su 
respuesta. 


18.9. ¿Quién debe llevar a cabo la prueba de validación —el 
desarrollador del software o el usuario—? Justifique su respuesta. 


18.10.  Desarrolleuna estrategia de prueba completa para el 
sistema HogarSeguro descrito anteriormente en este libro. 
Documéntela en una Especificación de Prueba. 


18.11.  Comoproyecto de clase, desarrolle una guía de depu- 
ración para su instalación. La guía debe proporcionar conse- 
jos orientados al lenguaje y al sistema que se hayan aprendido 
con las malas experiencias. Comience con un esbozo de los 
temas que se tengan que revisar por la clase y su profesor. 
Publique la guía para otras personas de su entorno. 


CUP 


Libros orientados a las estrategias de prueba del software son 
los de Black (Managing the Testing Process, Microsoft Press, 
1999), Dustin, Rashka and Paul (TestProcess [mprovement: 
Step-By-Step Guide to Structured Testing, Addison-Wesley, 
1999), Perry (Suwiving the Top Ten Challenges of Software 
Testing: A People-Oriented Approach, Dorset House, 1997), 
and Kit and Finzi (Software Testing in the Real World: Impro- 
ving the Process, Addison-Wesley, 1995). 

Kaner, Nguyen y Falk (Testing Computer Softwa-re, Wiley, 
1999), Hutcheson (Software Testing Methods and Metrics: 
The Most Important Tests, McGraw Hill, 1997), Marick (The 
Craft of Software Testing: Subsystem Testing Including Object- 
Based and Object-Oriented Testing, Prentice Hall, 1995), Jor- 
gensen (Software Testing: A Crafts-man 's Approach, CRC 
Press, 1995) presentan estudios sobre los métodos y estrate- 
gias de prueba. 

Además, antiguos libros de Evans (Productive Software 
Test Management, Wiley-Interscience, 1984), Hetzel (The 
Complete Guide to Software Testing, QED InformationScien- 
ces, 1984), Beizer [BEI84], Ould y Unwin (Testing in Soft- 
ware Development, Cambridge University Press, 1986), Marks 
(Testing Very Big Systems, McGraw-Hill, 1992), y Kaner et 
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al. (Testing Computer Software, 2.* ed., Van Nostrand Rein- 
hold, 1993) define los pasos para una estrategia efectiva, pro- 
porciona un conjunto de técnicas y directrices y sugiere 
procedimientos para controlar y hacer un seguimiento a los 
procesos de prueba. Hutcheson (Software Testing Methods 
and Metrics, McGraw-Hill, 1996) presenta unos métodos y 
estrategias de prueba pero también proporciona un estudio 
detallado de cómo se puede usar la medición para conseguir 
una prueba efectiva. 

Un libro de Dumn (Sofware Defect Removal, McGraw-Hill, 
1984) contiene unas directrices para la depuración. Beizer 
[BEI84] presenta una interesante «taxonomía de errores» que 
puede conducir a unos métodos efectivos para la planificación 
de pruebas. McConnell (Code Complete, Microsoft Press, 1993) 
presenta unos pragmáticos consejos sobre las pruebas de uni- 
dad y de integración así como sobre la depuración. 

Una amplia variedad de fuentesde información sobre prue- 
bas del software y elementos relacionados están disponibles 
en Internet. Una lista actualizada de páginas web sobre con- 
ceptos de prueba, métodos y estrategias pueden encontrarse 
en http://www.pressman5.com. 
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MÉTRICAS TÉCNICAS 
DEL SOFTWARE 


N elemento clave de cualquier proceso de ingeniería es la medición. Empleamos medi- 

das para entender mejor los atributos de los modelos que creamos. Pero, fundamental- 

mente, empleamos las medidas para valorar la calidad de los productos de ingeniería o 
de los sistemas que construimos. 

Adiferencia de otras disciplinas, la ingeniería del software no está basada en leyes cuanti- 
tativas básicas de la Física. Las medidas absolutas, tales como el voltaje, la masa, la veloci- 
dad o la temperatura no son comunes en el mundo del software. En su lugar, intentamos obtener 
un conjunto de medidas indirectas que dan lugar a métricas que proporcionan una indicación 
de la calidad de algún tipo de representación del software. Como las medidas y métricas del 
software no son absolutas, están abiertas a debate. Fenton [FEN91] trata este aspecto cuando 
dice: 


La medición es el proceso por el que se asignan números o símbolos a los atributos de las entidades en 
el mundo real, de tal manera que las definan de acuerdo con unas reglas claramente definidas ....En las cien, 
cias físicas, medicina y, más recientemente, en las ciencias sociales, somos ahora capaces de medir atribu- 
tos que previamente pensábamos que no eran medibles... Por supuesto, tales mediciones no están tanrefinadas 
como las de las ciencias físicas..., pero existen [y se toman importantes decisiones basadas en ellas]. Sen- 
timos que la obligación de intentar «medir lo no medible» para mejorar nuestra comprensión de entidades 
particulares es tan poderosa en la ingeniería del software como en cualquier disciplina. 


Pero algunos miembros de la comunidad de softwarecontinúan argumentando que el software 
no es medible o que se deberían posponer los intentos de medición hasta que comprendamos mejor 
el software y los atributos que habría que emplear para describirlo. Esto es un error. 


VISTAZO RÁPIDO 


datos históricos. El resultado 


¿Qué es? Por su naturaleza,la ingenie- necesita criterios objetivos para guiarse 


ía es una disciplina cuantitativa.Los 
ingenieros usan números para ayu- 


darse en el diseño y cálculo del pro-* 


ducto a construir. Hasta hace poco 
tiempo. losingenierosdel software dis- 
ponían de pocas referencias cuantita- 
tivas en su trabajo —pero esto está 
cambiando—. Las métricas técnicas 
ayudan a los ingenieros del software 
a profundizar en el diseño y construc- 
ción de los productos que desarrollan. 


¿Quién lo hace? Los ingenieros del soft- 


ware usan las métricas técnicas para 
ayudarse en el desarrollo de software 
de mayor calidad. 


¿Por qué esimportante? Siemprehabrá 


elementoscualitativospara la creación 
del software.El problema estribaen que 
la valoración cualitativapuede no ser 
suficiente.Un ingeniero del software 


en el diseño de datos, de la arquitectu- 
ra, de las interfaces y de los componen- 
tes. El verificador necesita una referencia 
cuentitativa que le ayude en la selección 
de los casos de prueba y de sus objeti- 
vos, Las métricas técnicas facilitan una 
base para que el análisis, diseño, codi- 
ficación y prueba puedan ser conduci- 
das más objetivamente y valoradas más 
cuantitativamente. 


¿Cuáles son los pasos? La primera eta- 


pa en el proceso de medida consiste en 
extraer las medidas y métricas del soft- 
ware que son apropiadas para la repre- 
sentación del software que está siendo 
considerado. Á continuación, se requie- 
ren datos para extraer la formulación de 
métricas agregadas. Una vez calculadas, 
las métricas apropiadas son analizadas 
en base a directrices preestablecidas y 


sis es interpretado para 


cación y prueba. 


¿Cuál es el producto obtenido? L Las 
métricas del software serán calculadas 
sobre datos agregados del análisis, de 
los modelos de diseño, del código fuen- ' 
“te y de los casos de prueba; e 

¿Cómo puedo estar seguro de que 
lo he hecho correctamente? Hay 
que establecer los objetivos y medidas 
antes de comenzar la acumulación de 
datos, definiendo siñ' ambigúedad 
cada métrica técnica. Define pocas 
métricas y utilízalas para profundizar 
en la calidad del resultado obtenido en 
la ingeniería del software. 


Aunque las métricas técnicas para el software de computadora no son absolutas, nos pro- 


porcionan una manera sistemática de valorar la calidad basándose en un conjunto de «reglas 
claramente definidas». También le proporcionan al ingeniero del software una visión interna en 
el acto, en vez de a posteriori. Esto permite al ingeniero descubrir y corregir problemas poten- 
ciales antes de que se conviertan en defectos catastróficos. 
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En el Capítulo 4 estudiábamos las métricas del software tal y como se aplican a nivel del proceso y del proyecto. En 
este capítulo, nuestro punto de atención se desplaza a las medidas que se pueden emplear para valorar la calidad del pro- 
ducto según se va desarrollando. Estas medidas de atributos internos del producto le proporcionan al desarrollador de soft- 
ware una indicación en tiemporeal de la eficacia del análisis, del diseño y de la estructura del código, la efectividad de los 
casos de prueba, y la calidad global del software a construir. 


Incluso los desarrolladores del software más hastiados 


estarán de acuerdo en que un software de alta calidad es 
una de las metas más importantes. Pero, ¿cómo definimos 
la calidad?En el Capítulo 8 propusimos diferentes mane- 
ras de interpretarla calidad del software e introdujimos 
una definición que hacía hincapié en la concordancia con 
los requisitos funcionales y de rendimiento explícitamen- 
te establecidos, los estándares de desarrollo explícitamente 
documentadosy las característicasimplícitas que se espe- 
ran de todo software desarrollado profesionalmente. 


ce algo correctamente, 
serlo que necesitamos que haga. 


No cabe duda de que la definición anterior podría 
modificase o ampliarse y discutirse eternamente. Para 
los propósitos de este libro, la definición sirve para hacer 
énfasis en tres puntos importantes: 


1. Los requisitos del software son la base de las medi- 
das de la calidad. La falta de concordancia con los 


requisitos es una falta de calidad". 


. Unos estándares específicos definen un conjunto de 
criterios de desarrollo que guían la manera en que se 
hace la ingeniería del software. Si no se siguen los 
criterios, habrá seguramente poca calidad. 


A 


Existe un conjunto de requisitos implícitos que a 
menudo no se nombran (por ejemplo, facilidad de 
mantenimiento). Si el softwarecumple con sus requi- 
sitos explícitos pero falla en los implícitos, la cali- 
dad del software no será fiable. 


La calidad del software es una compleja mezcla de 
factores que variarán a través de diferentes aplicacio- 
nes y según los clientes que las pidan. En las siguien- 
tes secciones, se identifican los factores de la calidad 
del software y se describen las actividades humanas 
necesarias para conseguirlos. 


19.1.1.Factores de calidad de McCall 


Los factores que afectan a a la calidad del software se 
pueden categorizar en dos amplios grupos: (1) factores 


1 Es importante resaltar que la calidad se extiendea los atributos téc- 
nicos de los modelos de análisis, de diseño y de codificación. Los 
modelos que presentan una alta calidad (enel sentido técnico) darán 
lugar a un software de una alta calidad desde el punto de vista del 
cliente. 
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que se pueden medir directamente (por ejemplo, defec- 
tos por punto de función) y (2) factores que se pueden 
medir sólo indirectamente (por ejemplo, facilidad de 
uso o de mantenimiento). En todos los casos debe apa- 
recer la medición. Debemos compararel software (docu- 
mentos, programas, datos) con una referencia y llegar 
a una conclusión sobre la calidad. 


“3 
LAVE 


Es interesante notar que los factores de calidad 
de McCall son ten válidos hoy como cuando fueron 
los primeros propuestos en los años 70. Aderrés 
es razonable indicar que los factores que afectan 
a la calidad del software no cambian. 


McCall y sus colegas [MCC77] propusieron una Útil 
clasificación de factores que afectan a la calidad del soft- 
ware. Estos factores de calidad del software, mostrados 
en la Figura 19.1, se concentran en tres aspectos impor- 
tantes de un producto software: sus características ope- 
rativas, su capacidad de cambios y su adaptabilidad a 
nuevos entornos. 


Facilidad de mantenimiento Portabilidad 
Flexibilidad Reusabilidad 
Facilidad de prueba Interoperatividad 


Revisión del producto ¡ón del producto 


Corrección Fiabilidad Usabilidad Integridad Eficiencia 


FIGURA 19.1. Factores de calidad de McCall 


Refiriéndose a los factores anotados en la Figura 19.1, 
McCall proporciona las siguientes descripciones: 


Corrección. Hasta dónde satisface un programa su especi- 
ficación y logra los objetivos propuestos por el cliente. 


Fiabilidad. Hasta dónde se puede esperar que un programa 
lleve a cabo su función con la exactitud requerida. Hay que 
hacer notar que se han propuesto otras definiciones de fiabili- 
dad más completas (vea el Capítulo 8). 
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Eficiencia.La cantidad de recursos informáticos y de códi- 
go necesarios para que un programa realice su función. 


Integridad. Hasta dónde se puede controlarel accesoal soft- 
ware o a los datos por personas no autorizadas. 


producto es una función 
úmbios del mundo por mejorar. 


Usabilidad (facilidadde manejo). El esfuerzonecesario para 
aprender a operar con el sistema, preparar los datos de entra- 
da e interpretar las salidas (resultados) de un programa. 


Facilidad de mantenimiento. El esfuerzo necesario para 
localizary arreglarun error en un programa. (Esta es una defi- 
nición muy limitada). 

Flexibilidad. El esfuerzo necesario para modificar un pro- 
grama que ya está en funcionamiento. 


Facilidad de prueba. El esfuerzo necesario para probar un 
programa y asegurarse de que realiza correctamente su fun- 
ción. 

Portabilidad. El esfuerzo necesario para transferir el pro- 


grama de un entorno hardware/software a otro entomo dife- 
rente. 


Reusabilidad (capacidad de reutilización). Hasta dónde se 
puede volver a emplear un programa (Opartes de un progra- 
ma) en otras aplicaciones, en relación al empaquetamiento y 
alcance de las funciones que realiza el programa. 


Interoperatividad.El esfuerzonecesario para acoplarun sis- 
tema con otro. 


Es difícil, y en algunos casos imposible, desarrollar 
medidas directas de los factores de calidad anteriores. 
Por tanto, se definen y emplean un conjunto de métri- 
cas para desarrollar expresiones para todos los factores, 
de acuerdo con la siguiente relación: 


Ea 


donde F_ es un factor de calidad del software, c, son 
coeficientes de regresión y m, son las métricas que afec- 
tan al factor de calidad. Desgraciadamente, muchas de 
las métricas definidas por McCall pueden medirse sola- 
mente de manera subjetiva. Las métricas pueden ir en 
forma de lista de comprobación que se emplea para 
«puntuar» atributos específicos del software [CAV78]. 
El esquema de puntuación propuesto por McCall es una 
escala del O (bajo) al 10 (alto). Se emplean las siguien- 
tes métricas en el esquema de puntuación: 


Referencia cruzada 


las métricas indicados puedenser valoradas 
en las revisiones técnicas formales referenciadas 
enel Capítulo 8, 


=C¡XM,+CXM)+....+C, XM, 


Facilidad de auditoría. La facilidad con la que se puede 
comprobar el cumplimeinto de los estándares. 


Exactitud. La exactitud de los cálculos y del control. 


Estandarización de comunicaciones. El grado de empleo 
de estándares de interfaces, protocolos y anchos de banda. 
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Complección. El grado con que se ha logrado la imple- 
mentación total de una función. 


Concisión.Lo compacto que es el programa en términos de 
líneas de código. 


Consistencia.El empleo de un diseño uniforme y de técni- 
cas de documentacióna lo largo del proyecto de desarrollo del 
software. 


Estandarizaciónde datos. El empleo de estructuras y tipos 
de datos estándares a lo largo del programa. 


Tolerancia al error. El daño causado cuando un programa 
encuentra un error. 


Eficiencia de ejecución. El rendimiento del funcionamien- 
to de un programa. 


Capacidad de expansión. El grado con que se pueden 
ampliar el diseño arquitectónico, de datos o procedimental. 


Generalidad. La amplitud de aplicación potencial de los 
componentes del programa. 


Independencia del hardware. El grado con que se desaco- 
pla el software del hardware donde opera. 


Instrumentación. El grado con que el programa vigila su 
propio funcionamiento e identificalos errores que ocurren. 


5 


3 


Factoresde Calidad 


Modularidud. La independenciafuncional (Capítulo 13) de 
componentes de programa. 


Operatividud.La facilidad de operación de un programa. 


Seguridad. La disponibilidad de mecanismos que contro- 
lan o protegen los programas y los datos. 


Autodocumentación. El grado en que el código fuente pro- 
porciona documentación significativa. 


Simplicidad. El grado de facilidad con que se puede enten- 
der un programa. 


Independencia del sistema software. El grado de indepen- 
dencia de programa respecto a las características del lenguaje 
de programación no estándar, características del sistema ope- 
rativo y otras restricciones del entorno. 


Trazabilidad.La capacidad de seguiruna representacióndel 
diseño o un componentereal del programa hasta los requisitos. 


Formación. El grado en que ayuda el software a manejar el 
sistema a los nuevos usuarios. 


La relación entre los factores de calidad del software 
y las métricas de la lista anterior se muestra en la Figura 
19.2. Debería decirse que el peso que se asigna a cada 
métrica depende de los productos y negocios locales. 


19.1.2. FURPS 


Los factores de calidad descritos por McCall y sus cole- 
gas [MCC77] representan sólo una de las muchas listas 
de comprobación sugeridas para la calidad del softwa- 
re. Hewlett-Packard [GRA87] ha desarrollado un con- 
junto de factores de calidad del software al que se le ha 
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dado el acrónimo de FURPS: funcionalidad, facilidad 
de uso,fiabilidad, rendimientoy capacidad de soporte. 
Los factores de calidad FURPS provienen de trabajos 
anteriores, definiendo los siguientes atributos para cada 
uno de los cinco factores principales: 


La funcionalidad se valora evaluando el conjunto de 
características y capacidades del programa, la gene- 
ralidad de las funciones entregadas y la seguridad 
del sistema global. 


Lafacilidad de uso se valora considerando factores 
humanos (capítulo 15), la estética, la consistencia y 
la documentación general. 


La fiabilidad se evalúa midiendo la frecuencia y gra- 
vedad de los fallos, la exactitud de las salidas (resul- 
tados), el tiempo de medio de fallos (TMDP), la 
capacidad de recuperación de un fallo y la capaci- 
dad de predicción del programa. 


El rendimiento se mide por la velocidad de procesa- 
miento, el tiempo de respuesta, consumo de recur- 
sos, rendimiento efectivo total y eficacia. 


La capacidad de soporte combina la capacidad de 
ampliar el programa (extensibilidad), adaptabilidad y 
servicios (estos tres atributos representan un término 
más común — mantenimiento —), asícomo capacidad 
de hacer pruebas, compatibilidad, capacidad de con- 
figuración (la capacidad de organizar y controlar ele- 
mentos de la configuración del software [Capítulo9)), 
la facilidad de instalación de un sistema y la facilidad 
con que se pueden localizar los problemas. 


Los factores de calidad FURPS y atributos descritos 
anteriormente pueden usarse para establecer métricas 
de la calidad para todas las actividades del proceso del 
software. 


19.1.3. Factores de calidad ISO 9126 


El estándar ISO 9126 ha sido desarrollado en un intento 
de identificarlos atributos clave de calidad para el soft- 
ware. El estándaridentifica seis atributos clave de calidad: 


Funcionalidad. El grado en que el software satisface las 
necesidades indicadas por los siguientes subatributos: idonei- 
dad, corrección, interoperatividad, conformidad y seguridad. 


Confiabilidad. Cantidadde tiempo que el software está dis- 
ponible para su uso. Está referido por los siguientes subatri- 
butos: madurez, toleranciaa fallos y facilidad de recuperación. 


Usabilidad. Grado en que el software es fácil de usar. Vie- 
ne reflejado por los siguientes subatributos: facilidad de com- 
prensión, facilidad de aprendizaje y operatividad. 


Eficiencia. Grado en que el software hace Óptimoel uso de 
losrecursos del sistema. Está indicado por los siguientessuba- 
tributos: tiempo de uso y recursos utilizados. 


Facilidad de mantenimiento. La facilidad con que una modi- 
ficación puede ser realizada. Está indicada por los siguientes 
subatributos: facilidad de análisis, facilidad de cambio, estabi- 
lidad y facilidad de prueba. 


Portabilidad. La facilidad con que el software puede ser 
llevado de un entorno a otro. Está referido por los siguientes 
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subatributos: facilidad de instalación, facilidad de ajuste, faci- 
lidad de adaptación al cambio. 


Creoliva requiere 
ora hacerlo bien, o perfecto 


Del mismo modo que los factores de calidad estu- 
diados en las secciones 19.1.1.y 19.1.2., los factores 
ISO 9126no necesariamente son utilizados para medi- 
das directas. En cualquier caso, facilitan una valiosa 
base para medidas indirectas y una excelente lista para 
determinar la calidad de un sistema. 


Métrica 
de la calidad 


calidad 


ficiencia 


Ll ppel pee [14 1] Ped] (1 | Mantenimiento 


Facilidad : 
de auditoría 
Exactitud 
Estandarización 

de comunicaciones 
«Compleción 
Complejidad 
Concisión 
Consistencia 


Estandarización 
le datos 
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| 
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Eficiencia de ejecución 
Capacidad de expansión 
Generalidad 
Independiencia 

del hardware 
Instrumentación 
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Facilidad de formación — EEE E ELA 


FIGURA 19.2. Factores y métricas de calidad. 


19.1.4, La transición a una visión cuantitativa 


En las secciones precedentes se estudiaron un conjun- 
to de factores cualitativospara la «medición» de la cali- 
dad del software. Intentamos desarrollarmedidas exactas 
de la calidad del software frustradas a veces por la natu- 
raleza subjetiva de la actividad. Cavano y McCall 
[CAV78] estudian esta situación: 


La determinación de la calidad es un factor clave en los 
acontecimientos diarios: concursos de cata de vinos, aconteci- 
mientos deportivos (por ejemplo, la gimnasia), concursos de 
talento, etc. En estas situaciones,la calidad sejuzga de la mane- 
ra más fundamental y directa: comparación de objetos unos al 
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lado de los otros bajo condiciones idénticas y con conceptos 
predeterminados. El vino puede serjuzgado de acuerdo con su 
claridad, color, bouquet, sabor, etc. Sin embargo, este tipo de 
juicio es muy subjetivo; para que tenga algo de valor, debe 
hacerse por un experto. 


La subjetividad y la especialización también influyen en la 
determinación de la calidad del software. Para resolver este 
problema, se necesita una definición de calidad del software 
más exacta, así como una manera de obtener medidas cuanti- 
tativas de la calidad del software para hacer un análisis objeti- 
vo.... Como no existe el conocimiento absoluto,no deberíamos 
esperar poder medir la calidad del software exactamente, ya 
que cada medición es parcialmente imperfecta. Jacob Bron- 
kowski describióesta paradoja del conocimiento de la siguien- 
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te manera: «Año tras año ingeniamos instrumentos más exac- 
tos con los que observar la naturaleza con más exactitud. Y 
cuando miramos las observacionesestamos desconcertados de 
ver que todavía son confusas, y tenemos la sensación de que 
son tan inciertas como siempre.» 


En las siguientes secciones examinamos un conjun- 
to de métricas del software que pueden aplicarse a la 
valoración cuantitativa de la calidad del software. En 
todos los casos, las métricas representan medidas indi- 
rectas; es decir, realmente nunca medimos la calidad 
sino alguna manifestación de la calidad. El factor que 
lo complica es la relación exacta entre la variable que 
se mide y la calidad del software. 


Como dijimos en la introducción de este capítulo, la medi- 
ción asigna números o símbolos a atributos de entidades 
en el mundo real. Para conseguirlo se necesita un mode- 
lo de medición que comprenda un conjunto consistente 
de reglas. Aunque la teoría de la medición (por ejemplo, 
[KYB84)]) y su aplicación al software (por ejemplo, 
[DEM81], [BRI96]) son temas que están más allá del 
alcance de este libro, merece la pena estableceruna estruec- 
tura fundamental y un conjunto de principios básicos para 
la medición de métricas técnicas para el software. 


le de referencia y evolucionan 
herramientas y técnicos, 
están madurando los medidas 


- 


19.2.1. El reto de las métricas técnicas 


Durante las pasadas tres décadas, muchos investigado- 
res han intentado desarrollar una sola métrica que pro- 
porcione una medida completa de la complejidad del 
software. Fenton [FEN94] caracteriza esta investiga- 
ción como una búsqueda del «imposible santo grial». 
Aunque se han propuesto docenas de medidas de com- 
plejidad [ZUS90], cada una tiene un punto de vista dife- 
rente de lo que es la complejidad y qué atributos de un 
sistema llevan a la complejidad. 


Referencia 


Voluminosa informaciónsobre métricas técnicas han sido 
recopiladaspor Horst Zuse: irb.es.tu-berlin.de /--zuse/ 
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Pero existe la necesidad de medir y controlar la com- 
plejidad del software. Y si es difícil de obtener un solo 
valor de esta «métrica de calidad», si debería ser posi- 
ble desarrollar medidas de diferentes atributos internos 
del programa (por ejemplo, modularidad efectiva, inde- 
pendencia funcional y otros atributos tratados desde el 
Capítulo 13al Capítulo 16). Estas medidas y las métri- 
cas obtenidas de ellas pueden usarse como indicadores 
independientes de la calidad de los modelos de análisis 
y diseño. Pero también surgen problemas aquí. Fenton 
[FEN94] lo advierte cuando dice: 

El peligro de intentar encontrar medidas que caractericen 
tantos atributos diferentes es que, inevitablemente, las medi- 
das tienen que satisfacerobjetivosincompatibles.Esto es con- 
trario a la teoría de representaciónde la medición. 

Aunque la declaración de Fenton es correcta, mucha 
gente argumenta que la medición técnica llevada a cabo 
durante las primeras fases del proceso de software les 
proporciona a los desarrolladores de software un con- 
sistente y objetivo mecanismo para valorar la calidad. 

Conviene preguntarse, no obstante, qué validez tie- 
nen las métricas técnicas. Es decir, ¿cómo están de pró- 
ximas las métricas técnicas y la fiabilidad y la calidad a 
largo plazo de un sistema basado en computadora? Fen- 
ton [FEN91] trata esta cuestión de la siguiente manera: 

Apesar de las intuitivas conexionesentre la estructurainter- 
na de los productos software (métricas técnicas) y su produc- 
to externo, y los atributos del proceso, ha habido, de hecho, 
muy pocos intentos científicos para establecerrelacionesespe- 
cíficas. Hay varias razones para ello; la que se menciona más 
a menudo es la imposibilidad de llevar a cabo experimentos. 

Todos los desafíos mencionados anteriormente son 
motivo de precaución, pero no es motivo de desprecio 
de las métricas técnicas” .La medición es esencial si se 
desea conseguir calidad. 


2 Seha producido una gran cantidad de literatura sobre las métricas del 
software (porejemplo, vea [FEN94], (ROC94], [ZUS97] para obtenerunas 
extensasbibliografías) y es común la crítica de métricas específicas (inclu- 
yendo algunasde las presentadasen este capítulo) Sin embargo,muchas 
de las críticas se concentran en aspectos esotéricos y pierden el obje- 
tivo primario de la medición en el mundo real: ayudar al ingenieroa 
establecer una manera sistemática y objetiva de conseguiruna visión 
interna de su trabajo y mejorar la calidad del producto como resultado. 
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19.2.2. Principios de medición 


Antes de introducir una serie de métricas técnicas que 
(1) ayuden a la evaluación de los modelos de análisis y 
diseño, (2) proporcionen una indicación de la compleji- 
dad de los diseños procedimentales y del código fuente, 
y (3) ayuden en el diseño de pruebas más efectivas, es 
importante entender los principios básicos de la medi- 
ción. Roche [ROC94] sugiere un proceso de medición 
que se puede caracterizar por cinco actividades: 

» formulación: la obtención de medidas y métricas del 
software apropiadas para la representación del soft- 
ware en cuestión. 

colección: el mecanismoempleado para acumular datos 
necesarios para obtener las métricas formuladas. 
análisis: el cálculo de las métricas y la aplicación de 
herramientas matemáticas. 


Cuáles son los pasos 
8% para un proceso 
de medición correcto? 


interpretación: la evaluación de los resultados de las 
métricas en un esfuerzo por conseguir una visión 
interna de la calidad de la representación. 
realimentación (feedback):recomendaciones obte- 
nidas de la interpretación de métricas técnicas trans- 
mitidas al equipo que construye el software. 

Los principios que se pueden asociar con la formula- 
ción de las métricas técnicas son los siguientes[ROC94]: 
+ Los objetivos de la medición deberían establecerse 
antes de empezar la recogida de datos. 

Todas las técnicas sobre métricas deberían definirse 


sin ambigiledades. 
¿Qué reglas debemos 


4 observar cuando 


establecemos medidas técnicas? 


Las métricas deberían obtenerse basándose en una 
teoría válida para el dominio de aplicación (por ejem- 
plo, las métricas para el diseño han de dibujarse sobre 
conceptos y principios básicos de diseño y deberían 
intentar proporcionar una indicación de la presencia 
de un atributo que se considera beneficioso). 

Hay que hacer las métricas a medida para acomodar 
mejor los productos y procesos específicos [BAS84]. 
Aunque la formulación es un punto de arranque crí- 
tico, la recogida y análisis son las actividades que diri- 
gen el proceso de medición. Roche [ROC94] sugiere 
los siguientes principios para estas actividades: 
Siempre que sea posible, la recogida de datos y el 
análisis debe automatizarse. 


UN 


Por encima de todo, intento obtener medidos técnicas 
simples. No te obsesiones por lo métrica «perfecta» 
porque no existe. 
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. Sedeberían aplicar técnicas estadísticas válidas para 
establecer las relaciones entre los atributos internos 
del producto y las características externas de la cali- 
dad (por ejemplo, ¿está correlacionado el nivel de 
complejidad arquitectónico con el número de defec- 
tos descubiertos en la producción?). 

Se deberían establecer una directrices de interpreta- 


ción y recomendaciones para todas las métricas. 


Además de los principios apuntados anteriormente, 
el éxito de una actividad de métrica está ligada al sopor- 
te de gestión. Se deben considerar los fondos, la for- 
mación y la promoción si se quiere establecer y mantener 
un programa de medición técnica. 


19.2.3. Características fundamentales de las 
métricas del software 


Se han propuesto cientos de métricas para el software, 
pero no todas proporcionan un soporte práctico para el 
desarrollador de software. Algunas demandan medi- 
ciones que son demasiado complejas, otras son tan eso- 
téricas que pocos profesionales tienen la esperanza de 
entenderlas y otras violan las nociones básicas intuiti- 
vas de lo que realmente es el software de alta calidad. 
Ejiogu [EJI91] define un conjunto de atributos que 
deberían acompañar a las métricas efectivas del soft- 
ware. La métrica obtenida y las medidas que conducen 
a ello deberían ser: 
simples y fáciles de calcular. Debería ser relativa- 
mente fácil aprender a obtener la métrica y su cál- 
culo no debería demandar un esfuerzo O cantidad de 


tiempo inusuales. 
> ¿Cómo podemos valorar 
la calidad de una métrica 
del software propuesta? 


empírica e intuitivamente persuasivas. La métrica 
debería satisfacer las nociones intuitivas del inge- 
niero sobre el atributo del producto en cuestión (por 
ejemplo, una métrica que mide la cohesión de un 
módulo debería aumentar su valor a medida que crece 
el nivel de cohesión). 


consistentes y objetivas. La métrica debería siempre 
producir resultados sin ambigijedad. Un tercer equipo 
debería ser capaz de obtener el mismo valor de 
métrica usando la misma información del software. 


consistentes en el empleo de unidades y tamaños. El 
cálculo matemático de la métrica debería emplear 
medidas que no conduzcan a extrañas combinacio- 
nes de unidades. Por ejemplo, multiplicando el 
número de personas de un equipo por las variables 
del lenguaje de programación en el programa resulta 
una sospechosa mezcla de unidades que no son intui- 
tivamente persuasivas. 

independientes del lenguaje de programación. Las 
métricas deberían basarse en el modelo de análi- 
sis, modelo de diseño o en la propia estructura del 
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programa. No deberían depender de los caprichos 
de la sintaxis o semántica del lenguaje de progra- 
mación. 

* uneficaz mecanismo para la realimentación de cali- 
dad. La métrica debería proporcionar, al desarrolla- 
dor de software, información que le lleve a un 
producto final de mayor calidad. 


Consuo 


La experiencia indica que una métrica técnica se usa 
únicamente si es intuitiva y fácil de calcular. Si se requiere 
docenas de «contadores» y se han de utilizarcomplejos 
cálculos, la métricano será ampliamente utilizado. 


CAPITULO 19 METRICAS TÉCNICAS DEL SOFTWARE 


Aunque la mayoría de las métricas de software 
satisfacen las características anteriores, algunas de la 
métricas comúnmente empleadas dejan de cumplir 
una O dos. Un ejemplo es el punto de función (trata- 
do en el Capítulo 4 y en este capítulo). Se puede argu- 
mentar? que el atributo consistente y objetivo falla 
porque un equipo ajeno independiente puede no ser 
capaz de obtener el mismo valor del punto de función 
que otro equipo que use la misma información del 
software. ¿Deberíamos entonces rechazar la medida 
PF? La respuesta es «¡por supuesto que no!». El PF 
proporciona una útil visión interna y por tanto pro- 
porciona un valor claro, incluso si no satisface un atri- 
buto perfectamente. 


El trabajo técnico en la ingeniería del software empie- 
za con la creación del modelo de análisis. En esta fase 
se obtienen los requisitos y se establece el fundamento 
para el diseño. Por tanto, son deseables las métricas téc- 
nicas que proporcionan una visión interna a la calidad 
del modelo de análisis. 


los modelos de datos, funciones y comportamientos 
son tratados en los Capítulos 11 y 12, 


Aunque han aparecido en la literatura relativamen- 
te pocas métricas de análisis y especificación, es posi- 
ble adaptar métricas obtenidas para la aplicación de un 
proyecto (Capítulo 4) para emplearlas en este contex- 
to. Estas métricas examinan el modelo de análisis con 
la intención de predecir el «tamaño» del sistema resul- 
tante. Es probable que el tamaño y la complejidad del 
diseño estén directamente relacionadas. 


Contraseña 
Funciones 


- | Consulta de sensor f' de interacción 


Usuario Interruptor del usuario con H______| 
de emergencia 


Datos de configuración del sistema j 


FIGURA 19.3. Parte del modelo de análisis del software de 
Hogar Seguro. 


3 Fíjese que se puede hacer un contra argumento igualmente vigo- 
roso. Tal es la naturaleza de las métricas del software 


19.3.1. Métricas basadas en la función 


La métrica de punto de función (PE) (Capítulo 4) se pue- 
de usar como medio para predecir el tamaño de un siste- 
ma que se va a obtener de un modelo de análisis. Para 
ilustrar el empleo de la métrica de PF en este contexto, 
consideramos una sencilla representación del modelo de 
análisis mostrada en la Figura 19.3. En la figura se repre- 
senta un diagrama de flujo de datos (Capítulo 12) de una 
función del sistema HogarSeguro*. La función gestiona 
la interacción con el usuario, aceptando una contraseña 
de usuario para activar/desactivar el sistema y permitien- 
do consultas sobre el estado de las zonas de seguridad y 
varios sensores de seguridad. La función muestra una serie 
de mensajes de petición y envía señales apropiadas de 
control a varios componentes del sistema de seguridad. 


Cons) 


Paraser Útil para el trabajo técnica, las medidas técnicas 
que apoyan latoma de decisión (ej: errores encontrados 
durante la prueba de unidad) deben ser agrupadas 
y normalizadasutilizando la métrica PF 
El diagrama de flujo de datos se evalúa para deter- 
minar las medidas clave necesarias para el cálculo de 
la métrica de punto de.función (Capítulo 4): 
+. número de entradas del usuario 
+ número de salidas del usuario 
+. número de consultas de usuario 
. número de archivos 
+ número de interfaces externas 


Tres entradas del usuario: contraseña,interruptor 
de emergencia y activar/desactivar aparecen en la 
figurajunto con dos consultas: consulta de zona y con- 
sulta de sensor. Se muestra un archivo (archivo de 


* HogarSeguro es un sistema de seguridad para el hogar que se ha 
usado como aplicación de ejemplo en capítulos anteriores 
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configuración del sistema). También están presentes 
dos salidas de usuarios (mensajes y estados del sen- 
sor) y cuatro interfaces externas (sensor de prueba, 
configuración de zona, activar/desactivar y alerta de 
alarma). Estos datos, junto con la complejidad apro- 
piada, se muestran en la Figura 19.4. 


Factor de ponderación 
Parámetro Cuenta Simple Media Compleja 
de medición 
Número de entradas Xx G) 4 B = 
del usuario 
Número de salidas Xx a e 
del usuario 
Nieradconutas[ 2 | Xx >) 4 E = 


Número de archivos [+] Xx G) 10 15 
Número de ines 4 | Xx O 7 10 
externas 7 


Cuenta total 


FIGURA 19.4. Cálculo de puntos de función 
para una función de Hogar Seguro. 


La cuenta total mostrada en la Figura 19.4debe ajus- 
tarse usando la ecuación (4.1): 


PF= cuenta-total x (0,65 +0,01 x X[F1]) 
Donde cuenta-total es la suma de todas las entradas PF 
obtenidasen la Figura 19.3 y F; (i=1 a 14) son «los valo- 
res de ajuste de complejidad». Para el propósito de este 
ejemplo, asumimos que >[F1] es 46 (un producto mode- 
radamente complejo). Por tanto: 


PF=50x [0,65 +(0,01 x 46)] =56 


Referencia 


Una introducción útil al PF ha sido elaborada 
por Capers Jones y puede ser localizada en: 
www.spr.com/ library/ Ofuncmet.htm 


Basándose en el valor previsto de PF obtenido del 
modelo de análisis, el equipo del proyecto puede esti- 
mar el tamaño global de implementación de las funcio- 
nes de interacción de HogarSeguro. Asuma que los datos 
de los que se disponen indican que un PF supone 60 
líneas de código (se va a usar un lenguaje orientado a 
objetos) y que en un esfuerzo de un mes-persona se pro- 
ducen 12PF. Estos datos históricos proporcionan al ges- 
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tor del proyecto una importante información de plani- 
ficación basada en el modelo de análisis en lugar de en 
estimaciones preliminares. 

Considerar que de los proyectos anteriores se han 
encontrado una media de 3 errores por punto de función 
durante las revisiones de análisis y diseño, y 4 errores 
por punto de función durante las pruebas unitaria y de 
integración. Estos datos pueden ayudar a valorar a los 
ingenieros del software la completitud de sus revisio- 
nes y las actividades de prueba. 


19.3.2. La Métrica bang 


Al igual que la métrica de punto de función, la métrica 
bang puede emplearse para desarrollar una indicación 
del tamaño del software a implementar como conse- 
cuencia del modelo de análisis. 

Desarrollada por DeMarco [DEM82], la métrica bang 
es «una indicación independiente de la implementación 
del tamaño del sistema». Para calcular la métrica bang, 
el desarrollador de software debe evaluar primero un 
conjunto de primitivas (elementos del modelo de aná- 
lisis que no se subdividen más en el nivel de análisis). 
Las primitivas [DEM82] se determinan evaluando el 
modelo de análisis y desarrollando cuentas para los 
siguientes elementos? 

Primitivas funcionales (PFu). Transformaciones (burbu- 


jas) que aparecen en el nivel inferior de un diagrama de flujo 
de datos (Capítulo 12). 


Elementos de datos (ED). Los atributos de un objeto de 
datos, los elementos de datos son datos no compuestos y apa- 
recen en el diccionario de datos. 


Objetos (OB).Objetos de datos tal y como se describen en 
el Capítulo 11. 


Relaciones (RE).Las conexiones entre objetos de datos tal 
y como se describen en el Capítulo 12. 


Estados(ES). El número de estados observablespor el usua- 
noen el diagrama de transición de estados (Capítulo 12). 


Transiciones (TR). El número de transicionesde estadoen 
el diagrama de transición de estados (Capítulo 12). 


lexionemos sobre una «nueva métrica» 
cur ... podemos preguntamos nosotros 
puntos básicos, «Qué pretendemos 


Además de las seis primitivas apuntadas arriba, se 
determinan las cuentas adicionales para: 


Primitivas modificadas de función manual (PMFu). Fun- 
ciones que caen fuera del límite del sistema y que deben modi- 
ficarse para acomodarse al nuevo sistema. 


5 El acrónimo apuntado entre paréntesis a continuación de la primi- 
tiva se emplea para denotar la cuenta de la primitiva particular;por 
ejemplo,PFu indica el número de primitivas funcionalespresenteen 
un modelo de análisis. 
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Elementosde datos de entrada (EDE). Aquellos elementos 
de datos que se introducen en el sistema. 


Elementos de datos de salida (EDS). Aquellos elementos 
de datos que se sacan del sistema. 


Elementos de datos retenidos (EDR). Aquellos elemen- 
tos de datos que son retenidos (almacenados) por el sistema. 


Muestras (tokens)de datos (TC), Las muestras de datos 
(elementos de datos que no se subdividen dentro de una pri- 
mitiva funcional) que existen en el límite de la i-ésima primi- 
tiva funcional (evaluada para cada primitiva). 


Conexiones de relación(RE). Las relaciones que conec- 
tan el i-ésimo objeto en el modelo de datos con otros objetos. 


DeMarco[DEM82] sugiere que la mayoría del soft- 
ware se puede asignar a uno de los dos dominios siguien- 
tes, dominio defunción o dominio de datos, dependiendo 
de la relación RE/PFu. Las aplicaciones de dominio de 
función (encontradas comúnmente en aplicaciones de 
ingeniería y científicas) hacen hincapié en la transfor- 
mación de datos y no poseen generalmente estructuras 
de datos complejas. Las aplicaciones de dominio de 
datos (encontradas comúnmente en aplicaciones de sis- 
temas de información) tienden a tener modelos de datos 
complejos. 

RE/PEu < 0,7 implica una aplicación de dominio de función 
0,8 < RE/PFu < 1,4indica una aplicación híbrida 


RE/PFu > 1,5 implica una aplicación de dominio de datos 


Como diferentes modelos de análisis harán una par- 
tición del modelo con mayor o menor grado de refina- 
miento. DeMarco sugiere que se emplee una cuenta 
media de muestra (token)por primitiva 


TC ¿yg = ETC, /PFu 


para controlarla uniformidad de la partición a través de 
muchos diferentes modelos dentro del dominio de una 
aplicación. 

Para calcular la métrica bang para aplicaciones de 

dominio de función, se emplea el siguiente algoritmo: 

Asignar a bang un valor inicial = 9; 

Mientras queden primitivas funcionales por evaluar 
Calcular cuenta-token alrededor del límite de la 
primitiva 1; 
Calcular el incremento PFu corregido (IPFUC) 
Asignar la primitiva a una clase 
Evaluar la clase y anotar el peso valorado 
Multiplicar IPFuC por el peso valorado 
bang = bang + ponderación IPFuC; 

FinMientras 


La cuenta-token se calcula determinando cuántos 
símbolos léxicos (tokens) diferentes son «visibles» 
[DEM82] dentro de la primitiva. Es posible que el núme- 
ro de símbolos léxicos (tokens)y el número de elementos 
de datos sea diferente, si los elementos de datos pueden 
moverse desde la entrada a la salida sin ninguna trans- 
formación interna. La IPFuC corregida se determina de 
una tabla publicada por DeMarco. A continuación, se 
presenta una versión muy abreviada: 
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Tei IPFuC 
2 1,0 
5 5,8 
10 16,6 
15 29,3 
20 43,2 


La ponderación valorada apuntada en el algoritmo 
anterior se calcula de dieciséis clases diferentes de pri- 
mitivas funcionales definidas por DeMarco. Se asigna 
una ponderación que va de 0,6 (encaminamiento sim- 
ple de datos) a 2,5 (funciones de gestión de datos) depen- 
diendo de la clase de la primitiva. 

Para aplicaciones de dominio de datos, se calcula la 
métrica bang mediante el siguiente algoritmo: 


Asignar a bang el valor inicial = 6; 


Mientras queden objetos por evaluar en el modelo de 
datos 


Calcular la cuenta de relaciones” del objeto i 
Calcular el incremento de OB corregido (I0BC); 
bang = bang + IOBC; 

FinMientras 


El IOBC corregido se determina también de una tabla 


publicada por DeMarco. A continuación se muestra una 
versión abreviada: 


REi IOBC 
1 1,0 
3 4,0 
6 9.0 


Una vez que se ha calculado la métrica bang, se pue- 
de emplear el historial anterior para asociarla con el 
esfuerzo y el tamaño. DeMarco sugiere que las organi- 
zaciones se construyan sus propias versiones de tablas 
IPFuC e IOBC para calibrar la información de proyec- 
tos completos de software. 


19.3.3. Métricas de la calidad de la especificación 


Davis y sus colegas [DAV93] proponen una lista de carac- 
terísticas que pueden emplearse para valorar la calidad del 
modelo de análisis y la correspondiente especificación de 
requisitos: especificidad (ausenciade ambigiiedad), com- 
pleción, corrección, comprensión,capacidad de verifica- 
ción, consistencia interna y externa, capacidad de logro, 
concisión, trazabilidad, capacidad de modificación, exac- 
titud y capacidad de reutilización. Además, los autores 
apuntan que las especificaciones de alta calidad deben 
estar almacenadas electrónicamente, ser ejecutables o al 
menos interpretables, anotadas por importanciay estabi- 
lidad relativas, con su versión correspondiente,organiza- 
das, con referencias cruzadas y especificadas al nivel 
correcto de detalle. 

Aunque muchas de las característicasanteriores pare- 
cen ser de naturaleza cualitativa, Davis [DAV93] sugle- 
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re que todas puedan representarse usando una o más 
métricas. Por ejemplo, asumimos que hay n, requisi- 
tos en una especificación, tal como 

N,= NN ap 
donde nes el número de requisitos funcionales y n npes 


el número de requisitos no funcionales (por ejemplo, 
rendimiento). 


9) 
Ga 
Para medir las característicasde la especificación, es 


necesario conseguir profundizar cuentitativamente en la 
especificidady en la completitud. 


Para determinar la especificidad (ausencia de ambi- 
giedad) de los requisitos. Davis sugiere una métrica 
basada en la consistencia de la interpretación de los revi- 
sores para cada requisito: 


0) = A 


donde n, es el número de requisitos para los que todos 
los revisores tuvieron interpretaciones idénticas. Cuan- 
to más cerca de 1 esté el valor de Q, menor será la ambi- 
giedad de la especificación. 

La compleción de los requisitos funcionales pueden 
determinarse calculando la relación 

0,=4, /(1,xn,) 

donde u, es el número de requisitos únicos de función, 
n, es el número de entradas (estímulos) definidos o 
implicados por la especificación y n, es el número de 
estados especificados. La relación Q, mide el porcen- 
taje de funciones necesarias que se han especificado 
para un sistema. Sin embargo, no trata los requisitos 
no funcionales. Para incorporarlos a una métrica glo- 
bal completa, debemos considerar el grado de valida- 
ción de los requisitos. 


0; =2M,/ m, + My) 
donde n, es el número de requisitos que se han valida- 


do como correctos y n” el número de requisitos que no 
se han validado todavía. 


Es inconcebible que el diseño de un nuevo avión, un 
nuevo chip de computadora o un nuevo edificio de ofi- 
cinas se realizara sin definir las medidas del diseño, 
sin determinar las métricas para varios aspectos de la 
calidad del diseño y usarlas para guiar la evolución del 
diseño. Y sin embargo, el diseño de sistemas comple- 
jos basados en computadora a menudo consigue pro- 
seguir sin virtualmente ninguna medición. La ironía 
es que las métricas de diseño para el software están 
disponibles, pero la gran mayoría de los desarrollado- 
res de software continúan sin saber que existen. 


que es apreciable, 
oprecioble, se hace apreciable. 


Las métricas de diseño para el software, como otras 
métricas del software, no son perfectas. Continúa el 
debate sobre la eficacia y cómo deberían aplicarse. 
Muchos expertos argumentan que se necesita más expe- 
rimentación hasta que se puedan emplear las métricas 
de diseño. Y sin embargo, el diseño sin medición es una 
alternativa inaceptable. 


$ Un estudio completo de las métricas de calidad de especificación 
está más allá del alcance de este capítulo. Vea [DAV93] para más 
detalles. 
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En las siguientes secciones examinamos algunas de 
las métricas de diseño más comunes para el software de 
computadora. Aunque ninguna es perfecta, todas pue- 
den proporcionar al diseñador una mejor visión interna 
y ayudar a que el diseño evolucione a un nivel superior 
de calidad. 


19.4.1. Métricas del diseño arquitectónico 


Las métricas de diseño de alto nivel se concentran en 
las característicasde la arquitecturadel programa (Capí- 
tulo 14) con especial énfasis en la estructura arquitec- 
tónica y en la eficiencia de los módulos. Estas métricas 
son de caja negra en el sentido que no requieren ningún 
conocimiento del trabajo interno de un módulo en par- 
ticular del sistema. 

Card y Glass [CAR90] definen tres medidas de la 
complejidad del diseño del software: complejidad 
estructural, complejidad de datos y complejidad del 
sistema. 

La complejidad estructural, S(i), de un módulo ¡ se 
define de la siguiente manera: 


S(i) =P cali) 
donde f 


out 


(19-1) 


(i) es la expansión' del módulo 1. 


7 Como se dijo en el estudio introducido en el Capítulo 13, la expan- 
sión (fyy) indica el número de módulos inmediatamente subordina- 
dos al módulo ¡, es decir, el número de módulos que son invocados 
directamente por el módulo i. 
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Las méticas pueden profundizar en la estructura, 
en los datos, y en la complejidad del sistema asodacb 
con el diseño arquitectónico. 


La complejidad de datos, D(i), proporciona una indi- 
cación de la complejidad en la interfaz interna de un 
módulo ¡ y se define como: 


D()=AD 1 old) +1] 
donde v(i) es el número de variables de entrada y sali- 
da que entran y salen del módulo i 

Finalmente, la complejidad del sistema, C(1), se defi- 
ne como la suma de las complejidades estructural y de 
datos, y se define como: 


C(i)= S(i) + D(1) (19.3) 


A medida que crecen los valores de complejidad, la 
complejidad arquitéctónica o global del sistema tam- 
bién aumenta. Esto lleva a una mayor probabilidad de 
que aumente el esfuerzo necesario para la integración 
y las pruebas. 


(19.2) 


¿Hay un camino para 
valorar la Complejidad 
de ciertos modelos 
arquitectónicos? 


Una métrica de diseño arquitectónico de alto nivel, 
propuesta por Henry y Kafura [HENS 1], también emplea 
la expansión y la concentración. Los autores definen 
una métrica de complejidad de la forma: 


MEK =longitud(i) x [£,(1) +£,(1)1? (19.4) 


donde la longitud(i) es el número de sentencias en len- 
guaje de programación en el módulo i y f;,(i) es la con- 
centración del módulo i Henry y Kafura amplían la 
definición de concentración y expansión presentadas 
en este libro para incluir no sólo el número de cone- 
xiones de control del módulo (llamadas al módulo), 
sino también el número de estructuras de datos del que 
el módulo i recoge (concentración) o actualiza (expan- 
sión) datos. Para calcular el MHK durante el diseño 
puede emplearse el diseño procedimental para estimar 
el número de sentencias del lenguaje de programación 
del módulo ¡. Como en las métricas de Card y Glass 
mencionadas anteriormente, un aumento en la métri- 
ca de Henry-Kafura conduce a una mayor probabili- 
dad de que también aumente el esfuerzo de integración 
y pruebas del módulo. 

Fenton [FEN91] sugiere varias métricas de morfo- 
logía simples (por ejemplo, forma) que permiten com- 
parar diferentes arquitecturas de programa mediante 
un conjunto de dimensiones directas. En la Figura 19.5, 
se pueden definir las siguientes métricas: 


tamaño =n +a 19.5 
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donde n es el número de nodos (módulos) y a es el 
número de arcos (líneas de control). Para la arquitectu- 
ra mostrada en la Figura 19.5, 


Nodo 


Arco 
Profundidad 


Anchura 
FIGURA 19.5. Métricas de morfología 


tamaño = 17+ 18=35 


profundidad= el camino más largo desde el nodo 
raíz (parte más alta) a un nodo hoja. Para la 
arquitectura mostrada en la Figura 19.5, la 
profundidad = 4. 


anchura = máximo número de nodos de cualquier 
nivel de la arquitectura. Para la arquitectura mostra- 
da en la Figura 19.5, la anchura = 6. 
Relación arco-a-nodo, y =a /n. 
que mide la densidad de conectividad de la arquitectu- 
ra y puede proporcionaruna sencillaindicación del aco- 
plamiento de la arquitectura. Para la arquitectura 
mostrada en la Figura 19.5, = 18/ 17=1,06. 


de ser visto como un rodeo. Este 
sario porque los humanos muchos 

mos copacitados para tomar decisiones 
jetividad [sin un soporte 


19.4.2. Métricas de diseño a nivel de compo- 
nentes 


Las métricas de diseño a nivel de componentes se con- 
centran en las características internas de los compo- 
nentes del software e incluyen medidas de las «3Cs» 
—la cohesión, acoplamiento y complejidad del módu- 
lo—. Estas tres medidas pueden ayudar al desarrolla- 
dor de software ajuzgar la calidad de un diseño a nivel 
de los componentes. 

Las métricas presentadas en esta sección son de caja 
blanca en el sentido de que requieren conocimiento del 
trabajo interno del módulo en cuestión. Las métricas de 
diseño de los componentes se pueden aplicar una vez 
que se ha desarrollado un diseño procedimental. Tam- 
bién se pueden retrasar hasta tener disponible el códi- 
go fuente. 
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Es posible colcular medidos de la independencia 


funcional, acoplamiento y cohesión de un componente 
y usarlos paro valorar la calidad y el diseño. 


air GU a ria 


Métricas de cohesión. Bieman y Ott [BIE94] defi- 
nen una colección de métricas que proporcionan una 
indicación de la cohesión (Capítulo 13) de un módulo. 
Las métricas se definen con cinco conceptos y medidas: 


Porción de datos. Dicho simplemente,una porción de datos 
es una marcha atrás a través de un módulo que busca valores 
de datos que afectan a la localización de módulo en el que empe- 
ZÓ la marcha atrás. Debería resaltarse que se pueden definir tan- 
to porciones de programas (que se centran en enunciados y 
condiciones) como porciones de datos. 


Muestras (tokens)de datos. Las variables definidas para 
un módulo pueden definirse como muestras de datos para el 
módulo. 


Señales de unión. El conjunto de muestras de datos que se 
encuentran en una o más porciones de datos. 


Señales de superunión. La muestras de datos comunes a 
todas las porciones de datos de un módulo. 


Pegajosidad. La pegajosidad relativa de una muestra de 
unión es directamente proporcional al número de porcionesde 
datos que liga. 


Bieman y Ott desarrollan métricas para cohesiones 
funcionalesfuertes (CFE), cohesionesfuncionales débi- 
les (CED) y pegajosidad (el grado relativo con el que 
las señales de unión ligan juntas porciones de datos). 
Estas métricas se pueden interpretar de la siguiente 
manera [BIE94]: 

Todas estas métricas de cohesión tienen valores que van de 
Oa 1. Tienen un valor de O cuando un procedimientotiene más 
de una salida y no muestra ningún atributo de cohesión indi- 
cado por una métrica particular. Un procedimiento sin mues- 
tras de superunión, sin muestras comunes a todas las porciones 
de datos, no tiene una cohesión funcional fuerte (no hay seña- 
les de datos que contribuyan a todas las salidas). Un procedi- 
miento sin muestras de unión, es decir, sin muestras comunes 
a más de una porción de datos (en procedimientos con más de 
una porción de datos), no muestra una cohesión funcionaldébil 
y ninguna adhesividad (no hay señales de datos que contribu- 

yan a más de una salida). 


La cohesión funcional fuerte y la pegajosidad se 
obtienen cuando las métricas de Bieman y Ott toman 
un valor máximo de 1. 

Se deja un estudio más detallado de las métricas de 
Bieman y Ott para que sean revisadas sus fuentes [BIE94]. 
Sin embargo, para ilustrar el carácter de estas métricas, 
considere la métrica para la cohesión funcional fuerte: 


CFE(G) = SU (SAYi)) / muestra(i) (19.6) 


donde SU (SA()) denota muestra de superunión (el con- 
junto de señales de datos que se encuentran en todas las 
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porciones de datos de un módulo ¿). Como la relación de 
muestras de superunión con respecto al número total de 
muestras en un módulo ¿ aumenta hasta un valor máximo 
de 1, la cohesión funcional del módulo también aumenta. 

Métricas de acoplamiento. El acoplamiento de 
módulo proporciona una indicación de la «conectivi- 
dad» de un módulo con otros módulos, datos globales 
y el entorno exterior. En el Capítulo 13, el acoplamien- 
to se estudió en términos cualitativos. 

Dhama [DHA95] ha propuesto una métrica para el 
acoplamiento del módulo que combina el acoplamien- 
to de flujo de datos y de control, acoplamiento global y 
acoplamiento de entorno. Las medidas necesarias para 
calcular el acoplamiento de módulo se definen en tér- 
minos de cada uno de los tres tipos de acoplamiento 
apuntados anteriormente. 

Para el acoplamiento de flujo de datos y de control: 

d; = número de parámetros de datos de entrada 
c; = número de parámetros de control de entrada 
d,, = número de parámetros de datos de salida 


Cc, = número de parámetros de control de salida 


Referencia 


Edocumento, «Sistema de métricas del software 
para el acoplamiento de módulos» podéis bajarlo de 
www.isse.gmu.edu/faculty /ofut/rsrch/ 
abstracts /mj-coupling.html 


Para el acoplamiento global: 
£¿ =número de variables globales usadas como datos 


£, = número de variables globales usadas como control 


Para el acoplamiento de entorno: 
w = número de módulos llamados (expansión) 


r =número de módulos que llaman al módulo en cuestión 
(concentración) 


Usando estas medidas, se define un indicador de aco- 
plamiento de módulo, »n,., de la siguiente manera: 
m, =k/M 
donde k=1 es una constante de proporcionalidad". 
M=d/+axc;+d,+bxc_+g¿+F0Xxg.+wctr 


donde a=b=c=2, 


Cuanto mayor es el valor de ,., menor es el aco- 
plamiento de módulo. Por ejemplo, si un módulo tiene 
un solo parámetro de entrada y salida de datos, no acce- 
de a datos globales y es llamado por un solo módulo: 


m,= 1/(1+0+ 1+0+0+0+1+0) =1/3=0,33. 


Deberíamos esperar que un módulo como éste presentara 
un acoplamiento bajo. De ahí que, un valor de m, =0,33 


8 El autor [DHA95] advierte que los valores de k y a, b y c (tratados 
en la siguiente ecuación)pueden ajustarse a medida que se van ven- 
ficando experimentalmente. 
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implica un acoplamientobajo. Porel contrario, si un módu- 
lo tiene 5 parámetros de salida y 5 parámetros de entrada 
de datos, un número igual de parámetros de control, acce- 
de a 10elementos de datos globales y tiene una concen- 
tración de 3 y una expansión de 4, 


m,_= 1/8+2x3+5+2x3+ 10+0 +3 +4) =0,02 


el acoplamiento implicado es grande. 

Para que aumente la métrica de acoplamientoa medi- 
da que aumenta el grado de acoplamiento,se puede defi- 
nir una métrica de acoplamiento revisada como: 


C=1-m, 


donde el grado de acoplamientono aumenta linealmente 
entre un valor mínimo en el rango de 0,66 hasta un máxi- 
mo que se aproxima a 1,0. 

Métricas de complejidad. Se pueden calcular una 
variedad de métricas del software para determinar la 
complejidad del flujo de control del programa. Muchas 
de éstas se basan en una representación denominada 
grafo de flujo. Tal y como se dijo en el Capítulo 17, un 
grafo es una representación compuesta de nodos y enla- 
ces (también denominados aristas). Cuando se dirigen 
los enlaces (aristas), el grafo de flujo es un grafo diri- 
gido. 

McCabe [MCC94] identifica un número importante 
de usos para las métricas de complejidad: 


Las métricas de complejidad pueden emplearse para pre- 
decir la información crítica sobre la fiabilidad y manteni- 
miento de sistemas softwarede análisis automáticos de código 
fuente (oinformación de diseño procedimental). Las métri- 
cas de complejidad también realimentan la información 
durante el proyecto de software para ayudar a controlar la 
[actividad del diseño]. Durante las pruebas y el manteni- 
miento, proporcionan una detallada información sobre los 
módulos software para ayudar a resaltar las áreas de inesta- 
bilidad potencial. 


La métrica de complejidad más ampliamente usada 
(y debatida) para el software es la complejidad ciclomá- 
tica, originalmente desarrollada por Thomas McCabe 
[MCC76] y estudiandocon detalle en la Sección 17.4.2. 

La métrica de McCabe proporciona una medida cuan- 
titativa para probar la dificultad y una indicación de la fia- 
bilidad última. Estudios experimentalesindican una fuerte 
correlación entre la métrica de McCabe y el número de 
errores que existen en el código fuente, así como el tiem- 
po requerido para encontrar y corregir dichos errores. 


» 
S 
Mo VE 


la complejidad ciclomática es solamenteuna más 
de los muchos métricas de complejidad. 


McCabe también defiende que la complejidad ciclo- 
mática puede emplearse para proporcionaruna indicación 
cuantitativa del tamaño máximo del módulo. Recogien- 
do datos de varios proyectos de programación reales, ha 
averiguado que una complejidad ciclomática de 10pare- 
ce ser el límite práctico superior para el tamaño de un 
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módulo. Cuando la complejidad ciclomáticade los módu- 
los excedían ese valor, resultaba extremadamente difícil 
probar adecuadamente el módulo. Vea en el Capítulo 17 
un estudio sobre la complejidad ciclomática como guía 
para el diseño de casos de prueba de caja blanca. 


19.4.3. Métricas de diseño de interfaz 


Aunque existe una significativa cantidad de literatura 
sobre el diseño de interfaces hombre-máquina (vea el 
Capítulo 15), se ha publicado relativamente poca infor- 
mación sobre métricas que proporcionen una visión inter- 
na de la calidad y facilidad de empleo de la interfaz. 
Sears [SEA93] sugiere la conveniencia de la repre- 
sentación (CR) como una valiosa métrica de diseño para 
interfaces hombre-máquina. Una IGU (Interfaz Gráfi- 
ca de Usuario) típica usa entidades de representación 
— iconos gráficos, texto, menús, ventanas y otras — para 
ayudar al usuario a completar tareas. Para realizar una 
tarea dada usando una IGU, el usuario debe moverse de 
una entidad de representación a otra. Las posiciones 
absolutas y relativas de cada entidad de representación, 
la frecuencia con que se utilizan y el «coste» de la tran- 
sición de una entidad de representación a la siguiente 
contribuirán a la conveniencia de la interfaz. 


¡ste de todos los partes 

puedo añadir, quitar o cambiar 
n la armonía del conjunto—. 
472). 


Para una representación específica (por ejemplo, un 
diseño de una IGU específica), se pueden asignar cos- 
tes a cada secuencia de acciones de acuerdo con la 
siguiente relación: 


Costes =) [frecuencia de transición (k) x 


X coste de transición (k)] (19.7) 


donde k es la transición específica de una entidad de 
representación a la siguiente cuando se realiza una tarea 
específica. Esta suma se da con todas las transiciones 
de una tarea en particular o conjunto de tareas requeri- 
das para conseguir alguna función de la aplicación. El 
coste puede estar caracterizado en términos de tiempo, 
retraso del proceso o cualquier otro valor razonable, tal 
como la distancia que debe moverse el ratón entre enti- 
dades de la representación. 

La convenienciade la representación se define como: 


CR =100 x [(costede la representación Óptima CR)/ 
/ (coste de la representación propuesta)] (19.8) 


donde CR = 100 para una representación Óptima. 


Para calcular la representación Óptima de una IGU, 
la superficie de la interfaz (el área de la pantalla) se divi- 
de en una cuadrícula. Cada cuadro de la cuadncula repre- 
senta una posible posición de una entidad de la 
representación. Para una cuadrículacon N posibles posi- 
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ciones y K diferentes entidades de representación para 
colocar, el número posible de distribuciones se repre- 
senta de la siguiente manera [SEA93]: 


número posible de distribuciones = 


=[N!/ (KK (N-K)3]xK! (19.9) 


A medida que crece el número de posiciones de repre- 
sentación, el número de distribuciones posibles se hace 
muy grande. Para encontrar la representación óptima 
(menor coste). Sears [SEA93] propone un algoritmo de 
búsqueda en árbol. 


Cons: 


las métricas del diseno de interface son válidas, pero 
sobre todo, son absolutamentenecesaros para asegurar 
que a los usuaniosfinales les agrada la inteface y estén 
sotistechos con los interacciones requeridas. 


La CR se emplea para valorar diferentes distribu- * 
ciones propuestas de IGU y la sensibilidadde una repre- 
sentaciónen particular a los cambios en las descripciones 
de tareas (por ejemplo, cambios en la secuencia y/o fre- 
cuencia de transiciones). El diseñador de interfacespue- 
de emplear el cambio en la conveniencia de la 
representación, ACR, como guía en la elección de la 
mejor representación de IGU para una aplicación en 
particular. 

Es importante apuntar que la selección de un diseño 
de IGU puede guiarse con métricas tales como CR, pero 
el árbitro final debería ser la respuesta del usuario basa- 
da en prototipos de IGU. Nielsen y Levy [NIE94] infor- 
man que «existe una gran posibilidad de éxito si se elige 
una interfaz basándose solamente en la opinión del usua- 
rio. El rendimiento medio de tareas de usuario y su satis- 
facción con la IGU están altamente relacionadas.» 


La teoría de Halstead de la ciencia del software [HAL77] 
es «probablemente la mejor conocida y más minucio- 
samente estudiada... medidas compuestas de la com- 
plejidad (software)» [CURSO]. La ciencia del software 
propone las primeras «leyes» analíticas para el softwa- 
re de computadora". 


sigue in conjunto rígido 
conoce [en el desarrollo 


La ciencia del software asigna leyes cuantitativas al 
desarrollo del software de computadora, usando un con- 
junto de medidas primitivas que pueden obtenerse una vez 
que se ha generado o estimado el código después de com- 
pletar el diseño. Estas medidas se listan a continuación. 

n,: el número de operadores diferentes que aparecen en el 
programa 


n,: el número de operandos diferentes que aparecen en el 
programa 


N,: el número total de veces que aparece el operador 


N,: el número total de veces que aparece el operando 


Consuof) 


los operadores incluyen todos las construcciones delflujo de 
control, condiciones y operaciones matemáticas. los operandos 
agrupan todos las variables y constantesdelprogramo. 


2 Se debería resaltar que las «leyes» de Halstead han generado una 
sustancial controversia y que no todo el mundo está de acuerdo con 
que la teoría subyacente sea correcta. Sin embargo, se han realizado 
verificaciones experimentales de las averiguaciones de Halstead para 
varios lenguajes de programación (porejemplo, [FEL89)). 
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Halstead usa las medidas primitivas para desarro- 
llar expresiones para la longitud global del programa; 
volumen mínimo potencial para un algoritmo; el volu- 
men real (número de bits requeridos para especificar 
un programa); el nivel del programa (una medida de 
la complejidad del software); nivel del lenguaje (una 
constante para un lenguaje dado); y otras característi- 
cas tales como esfuerzo de desarrollo, tiempo de desa- 
rrollo e incluso el número esperado de fallos en el 
software. 

Halstead expone que la longitud N se puede estimar 
como: 


N =n, log, n, +n, log, n, (19.10) 


y el volumen de programa se puede definir como: 


V=N log, (2, + 27) (19.11) 


Se debería tener en cuenta que V variará con el len- 
guaje de programación y representa el volumen de infor- 
mación (en bits) necesarios para especificar un 
programa. 

Teóricamente, debe existir un volumen mínimo para 
un algoritmo. Halstead define una relación de volumen 
L como la relación de volumen de la forma más com- 
pacta de un programa con respecto al volumen real del 
programa. Por tanto, L debe ser siempre menor de uno. 
En términos de medidas primitivas, la relación de volu- 
men se puede expresar como 


L =2/n, xn3/N, (19.12) 
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El trabajo de Halstead se presta a la verificación expe- 
rimental y de hecho se ha desarrollado una gran labor 
de investigación en la ciencia del software. Un estudio 
de este trabajo estaría fuera del alcance de este libro, 
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pero puede decirse que se ha llegado a un buen acuer- 
do entre lo previsto analíticamente y los resultados expe- 
rimentales. Para más información, vea [ZUS90], 
[FEN91] y [2US97]. 


Aunque se ha escrito mucho sobre las métricas del soft- 
ware para pruebas (por ejemplo, [HET93]), la mayoría 
de las métricas propuestas se concentran en el proceso 
de prueba, no en las características técnicas de las prue- 
bas mismas. En general, los responsables de las prue- 
bas deben fiarse de las métricas de análisis, diseño y 
código para que les guíen en el diseño y ejecución de 
los casos de prueba. 


a 
a 


CLAVE 


los métricos de lo prueba desembocanen los siguientes 
categorias: (1) métricas que ayudano determinar 

el número de pruebas requeridos en los distintos niveles 
de la prueba; (2)métricas poro cubrir la pruebo 

de un componente dado. 


Las métricas basadas en la función (Sección 19.3.1) 
pueden emplearse para predecir el esfuerzo global de 
las pruebas. Se pueden juntar y correlacionar varias 
características a nivel de proyecto (por ejemplo, esfuer- 
zO y tiempo para las pruebas, errores descubiertos, 
número de casos de prueba producidos) de proyectos 
anteriores con el número de PF producidos por un equi- 
po del proyecto. El equipo puede después predecir los 
valores «esperados» de estas característicasdel proyecto 
actual. 

La métrica bang puede proporcionar una indicación 
del número de casos de prueba necesarios para exami- 
nar las medidas primitivas tratadas en la sección 19.3.2. 
El número de primitivas funcionales (PFu), elementos 
de datos (DE), objetos (OB), relaciones (RE), estados 
(ES) y transiciones (TR) pueden emplearse para prede- 
cir el número y tipos de prueba del software de caja 
negra y de caja blanca. Por ejemplo, el número de prue- 
bas asociadas con la interfaz hombre-máquina se pue- 
de estimar examinando: (1) el número de transiciones 
(TR) contenidas en la representación estado-transición 
del IHM y evaluando las pruebas requeridas para eje- 
cutar cada transición, (2) el número de objetos de datos 
(OB) que se mueven a través de la interfaz y (3) el núme- 
ro de elementos de datos que se introducen o salen. 

Las métricas del diseño arquitectónico proporcionan 
información sobre la facilidad o dificultad asociada con 
la prueba de integración (Capítulo 18) y la necesidad 
de software especializado de prueba (por ejemplo, matri- 
ces y controladores). La complejidad ciclomática (una 
métrica de diseño de componentes) se encuentra en el 
núcleo de las pruebas de caminos básicos, un método 
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de diseño de casos de prueba presentado en el Capítu- 
lo 17. Además, la complejidad ciclomática puede usar- 
se para elegir módulos como candidatos para pruebas 
más profundas (Capítulo 18). Los módulos con gran 
complejidad ciclomáticatienen más probabilidad de ten- 
dencia a errores que los módulos con menor compleji- 
dad ciclomática. 

Por esta razón, el analista debería invertir un esfuerzo 
extra para descubrir errores en el módulo antes de inte- 
grarlo en un sistema. Es esfuerzo de las pruebas también 
se puede estimar usando métricas obtenidas de medidas 
de Halstead (Sección 19.5). Usando la definición del volu- 
men de un programa, V, y nivel de programa, NP, el 
esfuerzo de la ciencia del software, e, puede calcularse 
como: 


NP =1 /[(2,/2) x (N7/n,)1 
sia (19.13b) 


El porcentaje del esfuerzo global de pruebas a asig- 
nar a un módulo k se puede estimar usando la siguien- 
te relación: 


(19.13a) 


porcentaje de esfuerzo de pruebas (k) = 


e()/Le(1) (19.14) 


donde e(k) se calcula para el módulo k usando las 
ecuaciones (19.13) y la suma en el denominador de 
la ecuación (19.14) es la suma del esfuerzo de la cien- 
cia del software a lo largo de todos los módulos del 
sistema. 

A medida que se van haciendolas pruebas, tres medi- 
das diferentes proporcionan una indicación de la com- 
pleción de las pruebas. Una medida de la amplitud de 
las pruebas proporciona una indicación de cuantos 
requisitos (del número total de ellos) se han probado. 
Esto proporciona una indicación de la compleción del 
plan de pruebas. La profundidad de las pruebas es una 
medida del porcentaje de los caminos básicos indepen- 
dientes probados en relación al número total de estos 
caminos en el programa. Se puede calcular una estima- 
ción razonablemente exacta del número de caminos bási- 
cos sumando la complejidad ciclomática de todos los 
módulos del programa. Finalmente, a medida que se 
van haciendo las pruebas y se recogen los datos de los 
errores, se pueden emplear los perfiles defallos para dar 
prioridad y categorizarlos errores descubiertos. La prio- 
ridad indica la severidad del problema. Las categorías 
de los fallos proporcionan una descripción de un error, 
de manera que se puedan llevar a cabo análisis estadís- 
ticos de errores. 
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INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRACTICO 


Todas las métricas del software presentadas en este capí- 
tulo pueden usarse para el desarrollo de nuevo softwa- 
re y para el mantenimiento del existente. Sin embargo, 
se han propuesto métricas diseñadas explícitamentepara 
actividades de mantenimiento. 

El estándar EEE 982.1-1988|IEE94] sugiere un índi- 
ce de madurez del software (IMS) que proporciona una 
indicación de la estabilidad de un producto software (basa- 
da en los cambios que ocurren con cada versión del pro- 
ducto). Se determina la siguiente información: 


M,,= número de módulos en la versión actual 


F 


«= Número de módulos en la versión actual que se han 


cambiado 


F, número de módulos en la versión actual que se han aña- 
dido 


F' ¿número de módulos de la versión anterior que se han 
borrado en la versión actual 

El índice de madurez del software se calcula de la 
siguiente manera: 

IMS =[ Mp —(E¿+F.+F 11M (19.15) 

A medida que el IMS se aproxima a 1,0 el producto 
se empieza a estabilizar. ELIMS puede emplearse tam- 
bién como métrica para la planificación de las activi- 
dades de mantenimiento del software. El tiempo medio 
para producir una versión de un producto software pue- 
de correlacionarse con el IMS desarrollándose mode- 
los empíricos para el mantenimiento. 


Las métricas del software proporcionan una manera 
cuantitativa de valorar la calidad de los atributos inter- 
nos del producto, permitiendo por tanto al ingeniero 
valorar la calidad antes de construir el producto. Las 
métricas proporcionan la visión interna necesaria para 
crear modelos efectivos de análisis y diseño, un código 
sólido y pruebas minuciosas. 

Para que sea útil en el contexto del mundo real, una 
métrica del software debe ser simple y calculable, per- 
suasiva, consistente y objetiva. Debería ser indepen- 
diente del lenguaje de programación y proporcionar 
una realimentación eficaz para el desarrollador de soft- 
ware. 

Las métricas del modelo de análisis se concentran 
en la función, los datos y el comportamiento (los tres 
componentes del modelo de análisis). El punto de fun- 
ción y la métrica bang proporcionan medidas cuantita- 
tivas para evaluar el modelo de análisis. Las métricas 
del diseño consideran aspectos de alto nivel, del nivel 
de componentes y de diseño de interfaz. Las métricas 


de diseño de alto nivel consideran los aspectos arqui- 
tectónicos y estructurales del modelo de diseño. Las 
métricas de diseño de nivel de componentes propor- 
cionan una indicación de la calidad del módulo esta- 


bleciendo medidas indirectas de la cohesión, 
acoplamiento y complejidad. Las métricas de diseño de 
interfaz proporcionan una indicación de la convenien- 
cia de la representación de una IGU. 

La ciencia del software proporciona un intrigante 
conjunto de métricas a nivel de código fuente. Usando 
el número de operadores y operandos presentes en el 
código, la ciencia del software proporciona una varie- 
dad de métricas que pueden usarse para valorar la cali- 
dad del programa. 

Se han propuesto pocas métricas técnicas para un 
empleo directo en las pruebas y mantenimiento del soft- 
ware. Sin embargo, se pueden emplear muchas otras 
métricas técnicas para guiar el proceso de las pruebas 
y como mecanismo para valorar la facilidad de mante- 
nimiento de un programa de computadora. 
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19.1. La teoría de la medición es un tema avanzado que tie- 
ne una gran influencia en las métricas del software. Median- 
te [FEN91], [ZUS90] y [KYB84] u otras fuentes, escriba una 
pequeña redacción que recoja los principales principios de la 
teoría de la medición. Proyecto individual: Prepare una con- 
ferencia sobre el tema y expóngala en clase. 


19.2. Los factores de calidad de McCall se desarrollaron 
durante los años setenta. Casi todos los aspectos de la infor- 
mática han cambiado dramáticamente desde que se desarro- 
llaron, y sin embargo, los factores de McCall todavía se aplican 
en el software moderno. ¿Puede sacar algunaconclusión basa- 
da en este hecho? 


19.3. Por qué no se puede desarrollar una única métrica que 
lo abarque todo para la complejidad o calidad de un progra- 
ma? 


19.4. Revise el modelo de análisis que desarrolló como par- 
te del Problema 12.13. Mediante las directrices de la Sección 
19.3.1., desarrolle una estimación del número de puntos fun- 
ción asociadoscon SSRB. 


19.5. Revise el modelo de análisis que desarrolló como par- 
te del Problema 12.13. Mediante las directrices de la Sección 


339 


19.3.2., desarrolle cuentas primitivas para la métrica bang. ¿El 
sistema SSRB es de dominio de función o de datos? 


19.6. Calcule el valor de la métrica bang usando las medidas 
que desarrolló en el Problema 19.5. 


19.7. Cree un modelo de diseño completo para un sistema 
propuesto por su profesor. Calcule la complejidad estructural 
y de datos usando las métricas descritas en la Sección 19.4.1. 
Calcule también las métricas de Henry-Kafura y de morfolo- 
gía para el modelo de diseño. 


19.8. Un sistema de información grande tiene 1.140 módu- 
los. Hay 96 módulos que realizan funciones de control y coor- 
dinación, y 490 cuya función depende de un proceso anterior. 
El sistema procesa aproximadamente220 objetos de datos con 
una media de tres atributos por objeto de datos. Hay 140ele- 
mentos de la base de datos Únicos y 90 segmentos de base de 
datos diferentes. 600 módulos tienen un solo punto de entra- 
da y de salida. Calcule el ICDE del sistema. 


19.9. Investigueel trabajo de Bieman y Ott [BIE94] y desarro- 
lle un ejemplo completo que ilustre el cálculo de su métrica de 
cohesión. Asegúrese de indicar cómo se determinan las porcio- 
nes de datos, señales de datos y señales de unión y superunión. 
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19.10. Seleccione cinco módulos existentes de un progra- 
ma de computadora. Mediante la métrica de Dhama descrita 
en la Sección 19.4.2., calcule el valor de acoplamiento de 
cada módulo. 


19.11. Desarrolle una herramienta de software que calcule 
la complejidad ciclomática de un módulo de lenguaje de pro- 
gramación. Elija el lenguaje. 


19.12. Desarrolle una herramienta de software que calcule 
la conveniencia de la representación de una IGU. Esa herra- 
mienta debería permitirle asignar el coste de transición entre 
las entidades de la representación. (Nota: fíjese en que el tama- 
ño potencial del número de las altemativas de representación 
crece mucho a medida que aumenta el número de posibles 
posiciones de cuadrícula.) 


19.13. Desarrolle una pequeña herramienta de software que 
realice un análisis Halstead de un código fuente de un lenguaje 
de programación a su elección. 


19.14. Haga una investigacióny escribaun documento sobre 
la relación entre las métricas de la calidad del software de Hals- 
tead y la de McCabe (con respecto a la cuenta de errores). ¿Son 
convincentes los datos? Recomiende unas directrices para la 
aplicación de estas métricas. 


19.15. Investigue documentos recientes en busca de métri- 
cas específicamente diseñadas para el diseño de casos de prue- 
ba. Exponga los resultados en clase. 


19.16. Un sistema heredado tiene 940 módulos. La última 
versión requiere el cambio de 90 de estos módulos. Además, 
se añaden 40 módulos nuevos y se quitaron 12 módulos anti- 
guos. Calcule el índice de madurez del software del sistema. 


Sorprendentemente hay un gran número de libros dedicados 
a las métricas del software, aunque la mayoría están enfoca- 
dos a métricas de proceso y proyecto excluyendo las métri- 
cas técnicas. Zuse [2US97] ha escrito el más completo tratado 
de métricas técnicas publicado hasta la fecha. 

Los libros de Card y Glass [CAR90], Zuse [ZUS90], Fen- 
ton [FEN91], Ejiogu [EJ191], Moeller y Paulish (Métricas del 
Software, Chapman % Hall, 1993) y Hetzel [HET93] sonrefe- 
rencias sobre las métricas técnicas en detalle. Además, mere- 
ce la pena examinar los siguientes libros: 


Conte, S.D., H.E. Dunsmore, y V.Y. Shen, Software Engineering Metrics 
and Models, Benjamin/Cummings, 1984. 

Fenton, N.E., y S.L. Pfleeger, Software Metrics: A Rigorous andPrac- 
tical Approach, 2.* ed., PWS Publishing Co., 1998, 

Grady,R.B. Practical Software Metricsfor Project Mangement and Pro- 
cess Improvement,Prentice Hall, 1992, 

Perlis, A., et al., Software Metrics: An Analysis and Evalua- 
tion, MIT Press, 1981. 

Sheppard, M., Software Engineering Metrics, McGraw-Hill, 1992, 
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La teoría de la medición del software la presentan Den- 
vir, Herman, y Whitty en una colección de documentos 
(Proceedings of the International BCS-FACS Workshop: 
Formal Aspects of Measurement, Springer-Verlag, 1992). 
Shepperd (Foundations of Software Measurement, Prenti- 
ce Hall, 1996) también tratan la teoría de la medición en 
detalle. 


Una relación de docenas de usos de las métricas del soft- 
ware están presentadas en [1EE94]. En general, una discu- 
sión de cada métrica ha sido reducida a lo esencial «las 
primitivas» (medidas) requeridas para calcular las métricas 
y las adecuadas relaciones a efectos de los cálculos. Un apén- 
dice del libro suministra más información y referencias sobre 
el tema. 

Una amplia variedad de fuentes de información sobre 
métricas técnicas y elementos relacionados están disponi- 
bles en Intemet. Una lista actualizada de referencias de pági- 
nas web sobre métricas técnicas la puedes encontrar en 
http://www.pressman5.com. 
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PARTE 


IV 


INGENIERÍA 
DEL SOFTWARE 
ORIENTADA A OBJETOS 


n enfoque práctico considera- 
nedidas aplicables al análisis, 
bjetos. En los siguientes capí- 


N esta parte de Ingeniería del sojiwar 

mos los conceptos técnicos, m 

diseño y pruebas de software | 
tulos responderemos 1 las iguales preguntas 


orientado a objetos? 


- ¿En qué se diferencian el O E adi 


e ¿Cuáles son los conceptos y principios! bo 
software orientado a objetos? 


+ ¿Cómo cambian las estrategias de Did y dee métodos de diseño de casos 
de prueba cuando se considera el software orientado a objetos? : 


+ ¿Qué métricas técnicas están disponibles pea evaluar la calidad del soft- 
ware orientado a objetos? 


Una vez contestadas estas preguntas, comprenderá cómo analizar, diseñar, 
implementar y probar el software usando el paradigma de orientación a objetos. 
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CAPÍTULO 


20 


CONCEPTOS Y PRINCIPIOS 
ORIENTADOS A OBJETOS 


IVIMOS en un mundo de objetos. Estos objetos existen en la naturaleza, en entidades 

hechas por el hombre, en los negocios y en los productos que usamos. Pueden ser cla- 

sificados, descritos, organizados, combinados, manipulados y creados. Por esto no es 
sorprendente que se proponga una visión orientada a objetos para la creación de software de 
computadora, una abstracción que modela el mundo de forma tal que nos ayuda a entenderlo y 
gobernarlo mejor. 

La primera vez que se propuso un enfoque orientado a objetos para el desarrollo de softwa- 
re fue a finales de los años sesenta. Sin embargo, las tecnologías de objetos han necesitado casi 
veinte años para llegar a ser ampliamente usadas. Durante los años 90, la ingeniería del soft- 
ware orientada a objetos se convirtió en el paradigma de elección para muchos productores de 
software y para un creciente número de sistemas de información y profesionales de la ingenie- 
ría. A medida que pasa el tiempo, las tecnologías de objetos están sustituyendo a los enfoques 
clásicos de desarrollo de software. Una pregunta importante es: ¿Por qué? 

La respuesta (como muchas otras respuestas a interrogantes sobre ingeniería del software) 
no es sencilla. Algunas personas argumentarían que los profesionales del software sencilla- 
mente añoraban un nuevo enfoque, pero esta visión es muy simplista. Las tecnologías de obje- 
to llevan un número de beneficios inherentesque proporcionan ventajas alos niveles de dirección 
y técnico. 


VISTAZO RÁPIDO 


¿Qué es? Hay muchas formas de enfocar Esta importante característica permi- del problema, el diseño proporciona 


un problema utilizando una solución 
basada en el software. Un enfoque muy 
utilizado esla visión orientada a obje- 
tos. El dominiodel problema secaracte- 
riza mediante un conjuntod e objetos con 
atributosy comportamientosespecíficos. 
Los objetos son manipulados mediante 
una colección de funciones (llamadas 
métodos, operaciones O servicios) y se 
comunican entre ellos mediante un pro- 
tocolode mensajes. Los objetos seclasi- 
fican mediante clases y subclases, 


¿Quién lo hace? La definiciónde objetos 


implica la descripción deatributos,com- 
portamientos, operaciones y mensajes. 
Esta actividad la realiza un ingeniero 
del software. 


¿Por qué es importante? Un objeto 


encapsula tanto datos como los pro- 
cesos que se aplican a esos datos. 


te construir clases de objetos e inhe- 
rentemente construir bibliotecas de 
objetos y clases reutilizables. El para- 
digma de orientación a objetos es tan 
atractivo para tantas organizaciones 
de desarrollo de software debido a 
que la reutilización es un atributo 
importantísimo en la ingeniería. del 
software. Además, los componentes 
de software derivados mediante el 
paradigma de objetos muestran carac- 
terísticas (comola independencia fun- 
cional, la ocultación de información, 
etc.) asociadasconelsoftwarede alta 
calidad. 


¿Cuáles son los pasos? La ingeniería 


del software orientado a objetos sigue 
los mismos pasos que el enfoque con- 
vencional. El análisis identifica las cla- 
ses y objetos relevantes en el dominio 


detalles sobre la arquitectura, lasinter- 
faces y los componentes, la imple:* 
mentación (utilizando un lenguaje 
orientado a objetos)transíorma el dise- 
ño en código, y las pruebas chequean 
tanto la arquitectura como las interta- 
ces y los componentes. 


¿Cuál es el producto obtenido? Se 


produce un conjunto de modelos orien- 
tados a objetos. Estos modelos descri- 
ben los requisitos, el diseño, el código 
y los procesos de pruebas para un sis- 
tema o producto. 


¿Cómo puedo estar seguro de que 


lo he hecho correctamente? En 
cadaetapa serevisa la claridad delos 
productos de trabajo orientados aobje- 
tos, sucorrección, compleción y con- 
sistencia con los requisitos del cliente 
y entre ellos. 


Las tecnologías de objetos llevan a reutilizar, y la reutilización (de componente de softwa- 
re) lleva a un desarrollo de software más rápido y a programas de mejor calidad. El software 
orientado a objetos es más fácil de mantener debido a que su estructura es inherentemente poco 
acoplada. Esto lleva a menores efectos colaterales cuando se deben hacer cambios y provoca 
menos frustración en el ingeniero del software y en el cliente. Además, los sistemas orientados 
a objetos son más fáciles de adaptar y más fácilmente escalables (por ejemplo: pueden crearse 
grandes sistemas ensamblando subsistemas reutilizables). 

En este capítulo presentamos los principios y conceptos básicos que forman el fundamento 
para la comprensión de tecnologías de objetos. 
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INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRÁCTICO 


Durante muchos años el término orientado a objetos 
(OO Ye usó para referirse a un enfoque de desarrollo 
de software que usaba uno de los lenguajes orientados 
a objetos (Ada 95, C++, Eiffel, Smalltalk, etc.). Hoy en 
día el paradigma OO encierra una completa visión de 
la ingeniería del software. Edward Berard hace notar 
esto cuando declara [BER93]: 


Los beneficios de la tecnología orientada a objetos se for- 
talecen si se usa antes y durante el proceso de ingeniería del 
software.Esta tecnología orientada a objetos consideradadebe 
hacer sentir su impacto en todo el proceso de ingeniería del 
software. Un simple uso de programación orientada a objetos 
(POO) no brindará los mejores resultados. Los ingenieros del 
software y sus directores deben considerar tales elementos el 
análisis de requisitos orientado a objetos (AROO), el diseño 
orientado a objetos (DOO), el análisis del dominio orientado 
aobjetos(ADOO), sistemas de gestión de bases de dalos orien- 
tadas a objetos (SGBDOO)y la ingeniena del software orien- 
tada a objetos asistida por computadora(ISOOAC). 


los objetos es realmente más fácil construir 
modelos [paro sistemas complejos] que dedicarse o 
lo programación secuenciol 

David Taylor 


El lector familiarizadocon el enfoque convencional 
de ingeniería del software (presentada en la tercera par- 
te de este libro) puede reaccionar ante esta declaración 
con esta pregunta: «¿Cuál es la gran ventaja? Usamos 
el análisis, diseño, la programación, las pruebas y otras 
tecnologías relacionadas cuando realizamos ingeniería 
del software según métodos clásicos. ¿Por qué debe ser 
la OO diferente?» Ciertamente, ¿por qué debe ser la OO 
diferente? En pocas palabras, ¡no debiera! 


Identificar 
clases 
candidatas 


Análisis 


Comunicación Construir Buscar 
con el cliente n-ésima clases 
iteración en 


del sistema biblioteca 
Extraer 
nuevas 
clases si 
existen 


Añadir las 
nuevas | 

clases a la 

biblioteca |: 


WIYSIGIO, 


Construcción 
y Terminación 


Evaluación 
del ciente 


Desarrollar | * 
las clases F 


Programación OO 
Pruebas OO 


FIGURA 20.1. El modelo de proceso 00. 
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los sistemas 00 utilizan un modelo de ingeniería 
mediante proceso evolutivo. Más adelante, en este 
mismo capítulo, nos referiremos a él como el modelo 
recursivo paralelo. 


En el Capítulo 2, examinamos un número de mode- 
los de procesos diferentes para la ingeniería del softwa- 
re. Aunque ninguno de estos modelos pudo ser adaptado 
para su uso con OO, la mejor selección reconoceríaque 
los sistemas OO tienden a evolucionar con el tiempo. 
Por esto, un modelo evolutivo de proceso acoplado con 
un enfoque que fomenta el ensamblaje (reutilización) de 
componentes es el mejor paradigma para ingeniería del 
software OO. En la Figura 20.1 el modelo de proceso de 
ensamblaje de componentes (Capítulo 2) ha sido adap 
tado a la ingeniería del software OO. 


Una de las listos más completas de recursos DO 
en lo web puede consultarse en 
mini.net/cetus/software.html. 


El proceso VO se mueve a través de una espiral evo- 
lutiva que comienza con la comunicación con el usua- 
rio. Es aquí donde se define el dominio del problema y 
se identifican las clases básicas del problema (tratadas 
más tarde en este capítulo). La planificación y el análi- 
sis de riesgos establecen una base para el plan del pro- 
yecto OO. El trabajo técnico asociado con la ingeniería 
del software OO sigue el camino iterativo mostrado en 
la caja sombreada. La ingeniería del software OO hace 
hincapié en la reutilización. Por lo tanto, las clases se 


Clase: mobiliario 


costo 
Dimensiones 
Peso 
Localización 
Color 


El objeto hereda todos 
los atributos de la clase 


Objeto: silla 


Costo 
Dimensiones 
Peso 
Localización 
Color 


FIGURA 20.2. Herencia de clase a objeto. 
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buscan en una biblioteca (de clases VO existentes) antes 
de construirse. Cuando una clase no puede encontrarse 
en la biblioteca, el desarrollador de software aplica aná- 
lisis orientado a objetos (ADO), diseño orientado a obje- 
tos (DOO), programación orientada a objetos (POO) y 
pruebas orientadas a objetos (PROO) para crear la cla- 
se y los objetos derivados de la clase. La nueva clase se 
pone en la biblioteca de tal manera que pueda ser reu- 
tilizada en el futuro. 


CIPIOS ORIENTADOS A OBJETOS 


La visión orientada a objetos demanda un enfoque 
evolutivo de la ingeniería del software. Como veremos 
a través de este y los próximos capítulos, será extrema- 
damente difícil definir las clases necesarias para un gran 
sistema O producto en una sola iteracción.A medida que 
el análisis OO y los modelos de diseño evolucionan, se 
hace patente la necesidad de clases adicionales. Es por 
esta razón por lo que el paradigma arriba descrito fun- 
ciona mejor para la OO. 


Cualquier discusión sobre ingeniería del software 
orientada a objetos debe comenzar por el término 
orientado a objetos. ¿Qué es un punto de vista orien- 
tado a objetos? ¿Qué hace que un método sea consi- 
derado como orientado a objetos? ¿Qué es un objeto? 
Durante años han existido muchas opiniones diferen- 
tes (p. ej.: [BER93], [TAY90], [STR88], [BOO86]) 
sobre las respuestas correctas a estas preguntas. En los 
párrafos siguientes trataremos de sintetizar las más 
comunes de éstas. 


ientada a objetos no es tanto 
codificación de paquetes como 
elos constructores de software 
wlidades para proporcionárselas 


y 

Para entender la visión orientada a objetos, conside- 
remos un ejemplo de un objeto del mundo real —la cosa 
sobre la que usted está sentado ahora mismo—, una silla. 
Silla es un miembro (el término instancia también se 
usa) de una clase mucho más grande de objetos que lla- 
maremos Mobiliario. Un conjunto de atributos genéri- 
cos puede asociarse con cada objeto, en la clase 
Mobiliario. Por ejemplo, todo mueble tiene un costo, 
dimensiones, peso, localización y color, entre otros 
muchos posibles atributos. Estos son aplicables a cual- 
quier elemento sobre el que se hable, una mesa o silla, 
un sofá o un armario. Como Silla es un miembro de la 
clase Mobiliario, hereda todos los atributos definidos 
para dicha clase. Este concepto se ilustra en la Figura 
20.2 utilizando una notación conocida como UML. En 
dicha figura, la caja con una esquina doblada represen- 
ta un comentario en un lenguaje de programación. 

Una vez definida la clase, los atributos pueden reu- 
tilizarse al crear nuevas instancias de la clase. Por ejem- 
plo, supongamos que debemos definir un nuevo objeto 
llamado Sillesa (un cruce entre una silla y una mesa) 
que es un miembro de la clase Mobiliario. La Sillesa 
hereda todos los atributos de Mobiliario. 
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El objeto hereda 
todos los atributos 
y Operaciones de la clase 


Clase: mobiliario 


Costo 
Dimensiones 
Peso 

1 La ÉR 
Color 


Comprar 
Vender 
Pesar 
Mover 


Objetos: silla 


Costo 
Dimensiones 
Peso 
Localización 
Color 


Objetos: silla 


Costo 
Dimensiones 
Peso 
Localización 
Color 


Comprar 
Vender 

Pesar 
Mover 


FIGURA 20.3.Herencia operaciones de clase a objeto. 


Hemos intentado definir una clase describiendo sus atri- 
butos, pero algo falta. Todo objeto en la clase mobiliario 
puede manipularse de varias maneras. Puede comprarse 
y venderse, modificarse físicamente (por ejemplo, usted 
puede eliminar una pata o pintar el objeto de púrpura) o 
moverse de un lugar a otro. Cada una de estas operacio- 
nes (otros términos son servicios o métodos) modificará 
uno O más atributos del objeto. Por ejemplo, si el atributo 
localización es un dato compuesto definido como: 


localización = edificio + piso + habitación 


entonces una operación denominada mover modificaría 
uno o más de los elementos dato (edificio, piso o habi- 
tación) que conforman el atributo localización. Para 
hacer esto, mover debe tener «conocimiento»sobre estos 
elementos. La operación mover puede usarse para una 
silla o una mesa, debido a que ambas son instancias de 
la clase Mobiliario. Todas las operaciones válidas (por 
ejemplo, comprar, vender, pesar) de la clase Mobilia- 
rio están «conectadas» a la definición del objeto como 
se muestra en la Figura 20.3 y son heredadas por todas 
las instancias de esta clase. 
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INGENIERÍA DEL SOFTWARE. .., 
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Se puede utilizar lo notación de modelado de datos 
del Capitulo 12. 


El objeto silla (y todos los objetos en general) 
encapsula datos (los valores de los atributos que defi- 
nen la silla), operaciones (las acciones que se aplican 
para cambiar los atributos de la silla), otros objetos 
(pueden definirse objetos compuestos [EVB89]), cons- 
tantes (para fijar valores) y otra información relacio- 
nada. El encapsulamiento significa que toda esta 
información se encuentra empaquetada bajo un nom- 
bre y puede reutilizarse como una especificación o 
componente de programa. 


Ahora que hemos introducido algunos conceptos 
básicos, resultará más significativa una definición más 
formal de la «orientación a objetos». Coad y Yourdon 
[COA91] definen el término de la siguiente forma: 


orientación a objetos = 
=0bjetos + clasificación + herencia + comunicación 


Ya hemos introducido tres de estos conceptos. Pos- 
pondremos el tratamiento sobre la comunicación para 
más adelante. 


20.2.1. Clases y objetos 

Los conceptos fundamentales que llevan a un diseño de 
alta calidad (Capítulo 13) son igualmente aplicables a 
sistemas desarrollados usando métodos convencionales 
y orientados a objetos. Por esta razón, un modelo OO 
de software de computadora debe exhibir abstracciones 
de datos y procedimientos que conducen a una modu- 
laridad eficaz. Una clase es un concepto0O que encap- 
sula las abstracciones de datos y procedimientos que se 
requieren para describir el contenido y comportamien- 
to de alguna entidad del mundo real. Taylor [TAY90] 
usa la notación que se muestra a la derecha de la Figu- 
ra 20.4 para describir una clase (y objetos derivados de 
una clase). 


e, 
CLA VE 


Un objeto encapsula dotos (atributos) y los métodos 
(operaciones, métodoso servicios) que manipulan 
esos datos. 
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Las abstracciones de datos (atributos) que descri- 
ben la clase están encerradas por una «muralla» de 
abstracciones procedimentales (llamadas operacio- 
nes, métodos o servicios) capaces de manipular los 
datos de alguna manera. La Unica forma de alcanzar 
los atributos (y operar sobre ellos) es ir a través de 
alguno de los métodos que forman la muralla. Por lo 
tanto, la clase encapsula datos (dentro de la muralla) 
y el proceso que manipula los datos (los métodos que 
componen la muralla). Esto posibilita la ocultación 
de información y reduce el impacto de efectos cola- 
terales asociados a cambios. Como estos métodos 
tienden a manipular un número limitado de atributos, 
esto es una alta cohesión, y como la comunicación 
ocurre sólo a través de los métodos que encierra la 
«muralla», la clase tiende a un desacoplamiento con 
otros elementos del sistema. Todas estas caracterís- 
ticas del diseño (Capítulo 13) conducen a software 
de alta calidad. 


Nombre de clase 


Atributos: 


Atributos: 


Operaciones: 


FIGURA 20.4. Representación alternativa de una clase 
orientada a objetos. 


Puesto de otra manera, una clase es una descripción 
generalizada (por ejemplo, una plantilla, un patrón o 
un prototipo) que describe una colección de objetos 
similares. Por definición, todos los objetos que existen 
dentro de una clase heredan sus atributos y las opera- 
ciones disponibles para la manipulación de los atribu- 
tos. Una superclase es una colección de clases y una 
subclase es una instancia de una clase. 


Cons) 


Una delos primeros cosas o tener en cuentoo la hora 
de construir un sistemaDO es cómo clasificar los objetos 
o manipular en dicho sistema. 


Estas definiciones implican la existencia de una jerar- 
quía de clases en la cual los atributos y operaciones de 
la superclase son heredados por subclases que pueden 
añadir, cada una de ellas, atributos «privados» y méto- 
dos. Unajerarquía de clases para la clase Mobiliario se 
ilustra en la Figura 20.5. 
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20.2.2. Atributos 


Ya hemos visto que los atributos están asociados a cla- 
ses y objetos, y que describen la clase o el objeto de 
alguna manera. Un estudio de los atributos es presen- 
tado por de Champeaux y sus colegas [CHA93|]: 

Las entidades de la vida real están a menudo descritas con 
palabras que indican característicasestables. La mayoría de los 
objetos físicos tienen características tales como forma, peso, 
color y tipo de material. Las personas tienen características 
comofecha de nacimiento, padres, nombre y color delos ojos. 
Una característicapuede verse como una relación binaria entre 
una clase y cierto dominio. 


Mobiliario (superclase) 


al 


E 
Instancias de silla 


FIGURA 20.5. Unajerarquía de clases. 


Subclases de la 
superclase mobiliario 


La «relación» binaria anteriormente señalada impli- 
ca que un atributo puede tomar un valor definido por un 
dominio enumerado. En la mayoría de los casos, un 
dominio es simplemente un conjunto de valores espe- 
cíficos. Por ejemplo, suponga que una clase Cochetie- 
ne un atributo color. El dominio de valores de color es 
(blanco, negro, plata, gris, azul, rojo, amarillo, ver- 
de). En situaciones más complejas, el dominio puede 
ser un conjunto de clases. Continuando el ejemplo, la 
clase Coche también tiene un atributo motor que abar- 
ca los siguientes valores de dominio: [16 válvulas 
opción económica, 16 válvulas opción deportiva, 24 
válvulas opción deportiva, 32 válvulas opción de 
lujo).Cada una de las opciones indicadas tiene un con- 
junto de atributos específicos. 


a 

a 

los valores asignados a los atrioutos de un objeto hacen 
a ese objeto ser Único. 


Las características (valores del dominio) pueden 
aumentarse asignando un valor por defecto (caracte- 
rística) a un atributo. Por ejemplo, el atributo motor 
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destacado antes, tiene el valor por defecto 16 válvulas 
opción deportiva. Esto puede ser también Útil para 
asociar una probabilidad con una característica parti- 
cular a través de pares [ valor, probabilidad]. Conside- 
re el atributo color para Coche.En algunas aplicaciones 
(por ejemplo, planificación de la producción) puede ser 
necesario asignar una probabilidad a cada uno de los 
colores (blanco y negro son más probables como colo- 
res de coches). 


20.2.3. Operaciones, métodos y servicios 


Un objeto encapsula datos (representados como una 
colección de atributos) y los algoritmos que procesan 
estos datos. Estos algoritmos son llamados operaciones, 
métodos o servicios' y pueden ser vistos como módu- 
los en un sentido convencional. 


Y 
a 


CLAVE 


Serge que un objeto es estimulado por un mensaje, 
inicia algún comportamiento ejsoutanco uno operación. 


Cada una de las operaciones encapsuladas por un 
objeto proporciona una representación de uno de los 
comportamientos del objeto. Por ejemplo, la opera- 
ción DeterminarColor para el objeto Coche extraerá 
el color almacenado en el atributo color. La conse- 
cuencia de la existencia de esta operación es que la 
clase Coche ha sido diseñada para recibir un estímu- 
lo [JAC92] (llamaremos al estímulo mensaje) que 
requiere el color de una instancia particular de una cla- 
se. Cada vez que un objeto recibe un estímulo, éste ini- 
cia un cierto comportamiento, que puede ser tan simple 
como determinar el color del coche o tan complejo 
como la iniciación de una cadena de estímulos que se 
pasan entre una variedad de objetos diferentes. En este 
último caso, considere un ejemplo en el cual el estí- 
mulo inicial recibido por el objeto n.? 1 da lugar a una 
generación de otros dos estímulos que se envían al 
objeto n.* 2 y al objeto n.* 3. Las operaciones encap- 
suladas por el segundo y tercer objetos actúan sobre 
el estímulo devolviendo información necesaria para el 
primer objeto. El objeto n.* 1 usa entonces la infor- 
mación devuelta para satisfacer el comportamiento 
demandado por el estímulo inicial. 


20.2.4. Mensajes 


Los mensajes son el medio a través del cual interactúan 
los objetos. Usando la terminología presentadaen la sec- 
ción precedente, un mensaje estimula la ocurrencia de 
cierto comportamientoen el objeto receptor. El compor- 
tamiento se realiza cuando se ejecuta una operación. 


1 Usaremos aquí el término operaciones, pero métodos y servicios 
son igualmente populares. 
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INGENIERÍA DEL SOFTWARE. un ENrUQUE FRAL LIO 


En la Figura 20.6. se ilustra esquemáticamente la 
interacción entre objetos. Una operación dentro de un 
objeto emisor genera un mensaje de la forma: 


destino.operación (parámetros) 


donde destino define el objeto receptor el cual es esti- 
mulado por el mensaje, operación se refiere al método 
que recibe el mensaje y parúmetros proporciona infor- 
mación requerida para el éxito de la operación. 


Emisor.operación 


Objeto 
(parámetros) 


emisor 


Receptor.operación 


(parámetros) Objeto 


receptor 


FIGURA 20.6. Paso de mensaje entre objetos. 


Como un ejemplo de paso de mensajes dentro de un 
sistema OO, considere los objetos que se muestran en 
la Figura 20.7. Los cuatro objetos. A, B, C y D secomu- 
nican unos con otros a través del paso de mensajes. Por 
ejemplo, si el objeto B requiere el proceso asociado con 
la operación op10 del objeto D, el primero enviaría a D 
un mensaje de la forma: 


D.op lO(datos) 


Como parte de la ejecución de 0p10, el objeto D pue- 
de enviar un mensaje al objeto C de la forma: 


C.op8(datos) 


C encuentra op8, la ejecuta, y entonces envía un valor 
de retorno apropiado a D, La operación op10 completa 
su ejecución y envía un valor de retorno a B. 


Cox [COX86] describe el intercambio entre objetos 
de la siguiente manera: 


Se solicita de un objeto que ejecute una de sus operacio- 
nes enviándole un mensaje que le informa acerca de lo que 
debe hacer. El [objeto] receptor responde al mensaje eli- 
giendo primero la operación que implementa el nombre del 
mensaje, ejecutando dicha operación y después devolvien- 
do el control al objeto que origina la llamada. 
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El paso de mensajes mantiene comunicado un sistema 
orientado a objetos. Los mensajes proporcionan una 
visión interna del comportamiento de objetos indivi- 
duales, y del sistema OO como un todo. 


de retorno 


FIGURA 20.7. Paso de mensajes entre objetos. 


20.2.5. Encapsulamiento,herencia y polimorfismo 


Aunque la estructura y terminología introducida entre las 
Secciones 20.2.1 y 20.2.4 diferencian los sistemas 00 a 
partir de sus componentes convencionales, hay tres carac- 
terísticas de los sistemas orientados a objetos que los hacen 
Únicos. Como ya hemos observado, las clases y los obje- 
tos derivados de ella encapsulan los datos y las operacio- 
nes que trabajan sobre estos en un único paquete. Esto 
proporciona un número importante de beneficios: 


¿8 ¿Cuáles son los beneficios 
principales de una arquitectura 00? 


Los detalles de implementación interna de datos y 
procedimientos están ocultos al mundo exterior (ocul- 
tación de la información). Esto reduce la propaga- 
ción de efectos colaterales cuando ocurren cambios. 
Las estructuras de datos y las operaciones que las 
manipulan están mezcladas en una entidad sencilla: 
la clase. Esto facilita la reutilización de componentes. 
Las interfaces entre objetos encapsulados están sim- 
plificadas. Un objeto que envía un mensaje no tiene 
que preocuparse de los detalles de las estructuras de 
datos internas en el objeto receptor, lo que simpli- 
fica la interacción y hace que el acoplamiento del sis- 
tema tienda a reducirse. 


La herencia es una de las diferencias clave entre sis- 
temas convencionales y sistemas OO. Una subclase Y 
hereda todos los atributos y operaciones asociadas con 
su superclase X. Esto significa que todas las estructu- 
ras de datos y algoritmos originalmente diseñados e 
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implementados para X están inmediatamente disponi- 
bles para Y (noes necesario más trabajo extra). La reu- 
tilización se realiza directamente. 

Cualquier cambio en los datos u operaciones conte- 
nidas dentro de una superclase es heredado inmediata- 
mente por todas las subclases que se derivan de la 
superclase”. Debido a esto, lajerarquía de clases se con- 
vierte en un mecanismo a través del cual los cambios 
(a altos niveles) pueden propagarse inmediatamente a 
través de todo el sistema. 

Es importante destacar que en cada nivel de la jerar- 
quía de clases, pueden añadirse nuevos atributos y ope- 
raciones a aquellos que han sido heredados de niveles 
superiores de la jerarquía. De hecho, cada vez que se 
debe crear una nueva clase, el ingeniero del software 
tiene varias opciones: 


La clase puede diseñarse y construirse de la nada. 
Esto es, no se usa la herencia. 

Lajerarquía de clases puede serrastreada para deter- 
minar si una clase ascendiente contiene la mayoría 
de los atributos y operaciones requeridas. La nueva 
clase hereda de su clase ascendiente, y pueden aña- 
dirse otros elementos si hacen falta. 


La jerarquía de clases puede reestructurarse de tal 
manera que los atributos y operaciones requeridos 
puedan ser heredados por la nueva clase. 

Las características de una clase existente pueden 
sobrescribirse y se pueden implementar versiones pri- 
vadas de atributos u Operaciones para la nueva clase. 


e 


objeto es una entidod que existe 
eÉmpo y en el espacio, una close represento 
tracción, «la esencia» del objeto, 

a así, 


Para ilustrar cómo la reestructuración de la jerarquía 
de clases puede conducir a la clase deseada, considere el 
ejemplo mostrado en la Figura 20.8. Lajerarquía de cla- 
ses ilustradas en la Figura 20.84 nos permite derivar las 
clases X3 y X4 con las características 1, 2, 3, 4, 5 y 6, y 
1,2, 3, 4, 5 y 7, respectivamente”. Ahora, suponga que 
se desea crear una nueva clase solamente con las carac- 
terísticas 1,2, 3,4 y 8. Para derivar esta clase, llamada 
X2b en el ejemplo, lajerarquía debe reestructurarsecomo 
se muestra en la Figura 20,8b, Es importantedarse cuen- 
ta de que la reestructuraciónde lajerarquía puede ser difí- 
cil y, por esta razón, se usa a veces la anulación. 

En esencia, la anulación ocurre cuando los atributos y 
Operaciones se heredan de manera normal, pero después 
son modificados según las necesidades específicas de la 


2 A veces se emplean los términos descendiente y antecesor [JAC92] 
en lugar de subclase y superclase. 
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nueva clase. Como señala Jacobson, cuando se emplea la 
anulación, «la herencia no es transitiva» [JAC92]. 

En algunos casos, es tentador heredar algunos atributos 
y Operacionesde una clase y otrosde otra clase. Esta acción 
se llama herencia múltiple y es controvertida. En general, 
la herencia múltiple complica la jerarquía de clases y crea 
problemas potenciales en el control de la configuración 
(Capitulo 9). Como las secuencias de herencia múltiple son 
más difícilesde seguir,los cambiosen la definición de una 
clase que reside en la parte superiorde lajerarquía pueden 
tener impactos no deseados originalmenteen las clases defi- 
nidas en zonas inferiores de la arquitectura. 


o] puede ser extraño, pero el 


elegancia. 


El polimorfismo es una característica que reduce en 
gran medida el esfuerzo necesario para extender un sis- 
tema OO. Para entender el polimorfismo, considere una 
aplicación convencional que debe dibujar cuatro tipos 
diferentes de gráficos: gráficos de líneas, gráficos de tar 
ta, histogramas y diagramas de Kiviat. Idealmente, una 
vez que se han recogido los datos necesarios para un tipo 
particular de gráfico, el gráfico debe dibujarse él mismo. 
Pararealizar esto en una aplicaciónconvencional (y man- 


3 En este ejemplo llamaremos característica tanto a los atributos como 
a las operaciones. 


www.elsolucionario.net 


INGENIERÍA DEL SOFTWARE. Lis iru rama 


tener la cohesión entre módulos), sería necesario desa- 
rrollar módulos de dibujo para cada tipo de gráfico. Según 
esto, dentro del diseño para cada tipo de gráfico, se debe- 
rá añadir una lógica de control semejante a la siguiente: 


Case of tipo—grafico: 
1f tipo—grafico = grafico_linea then 
DibujarLinea (datos); 
1f tipo-grafico = grafico_tarta then 
DibujarTarta (datos); 
1f tipo-grafico = grafico_histograma 
then DibujarHisto (datos); 
1f tipo—grafico grafico_kiviat then 
DibujarKiviat (datos); 


end case; 


Aunque este diseño es razonablemente evidente, aña- 
dir nuevos tipos de gráficos puede ser complicado, pues 
hay que crear un nuevo módulo de dibujo para cada tipo 
de gráfico y actualizar la lógica de control para cada 
gráfico. 

Para resolver este problema, cada uno de los gráfi- 
cos mencionados anteriormente se convierte en una sub- 
clase de una clase general llamada Gráfico. Usando un 
concepto llamado sobrecarga [TAY90], cada subclase 
define una operación llamada dibujar. Un objeto pue- 
de enviar un mensaje dibujar a cualquiera de los obje- 
tos instanciados de cualquierade las subclases. El objeto 
que recibe el mensaje invocará su propia operación dibu- 

jar para crear el gráfico apropiado. Por esto, el diseño 
mostrado anteriormente se reduce a: 


tipo—grafico dibujar 


Cuando hay que añadir un nuevo tipo de gráfico al 
sistema, se crea una subclase con su propia operación 


Los elementos de un modelo de objetos -clases y obje- 
tos, atributos, operaciones y mensajes — fueron definidos 
y examinadosen la sección precedente. Pero, ¿cómo pode- 
mos hacer para identificar estos elementosen un proble- 
ma real? Las secciones que siguen presentan una serie de 
directrices informales que nos ayudarán en la identifica- 
ción de los elementos de un modelo de objetos. 


20.3.1. Identificación de clases y objetos 


Si usted observa a su alrededor en una habitación, exis- 
ten un conjunto de objetos físicos que pueden ser fácil- 
mente identificados, clasificados y definidos (en términos 
de atributos y operaciones). Pero cuandousted «observa» 
el espacio de un problema en una aplicación de software, 
los objetos pueden ser más difíciles de identificar. 
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descubri de primeras 


Podemos empezar a identificar objetos* examinando 
el planteamiento del problema o (usando la terminolo- 
gía del Capítulo 12) realizando un «análisis sintáctico 
gramatical» en la narrativa del sistema que se va a cons- 
truir. Los objetos se determinan subrayando cada nom- 
bre o cláusula nominal e introduciéndola en una tabla 
simple. Los sinónimos deben destacarse. Si se requie- 
re del objeto que implemente una solución, entonces 


4 En realidad, el Análisis VO intenta identificar las clases a partir de 
las cuales se instancian los objetos. Por tanto, cuando aislamos obje- 
tos potenciales, también identificamos miembros de clases poten- 
ciales. 
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éste formará parte del espacio de solución; en caso de 
que el objeto se necesite solamente para describir una 
solución, éste forma parte del espacio del problema. 
Pero, ¿qué debemos buscar una vez que se han aislado 
todos los nombres? 


¿Cómo identificar objetos 
cuando estudio cómo 
resolver un problema? 


Los objetos se manifiestan de alguna de las formas 
mostradas en la Figura 20.9. y pueden ser: 


entidades externas (por ejemplo: otros sistemas, dis- 
positivos, personas) que producen O consumen infor- 
mación a usar por un sistemas computacional; 


cosas (por ejemplo: informes, presentaciones, car- 
tas, señales) que son parte del dominio de informa- 
ción del problema; 


ocurrencias o sucesos” (por ejemplo: una transfe- 
rencia de propiedad o la terminación de una serie de 
movimientos en un robot) que ocurren dentro del 
contexto de una operación del sistema; 


papeles o roles (por ejemplo: director,ingeniero, ven- 
dedor) desempeñados por personas que interactúan 
con el sistema; 


unidades organizacionales (por ejemplo: división, 
grupo, equipo) que son relevantes en una aplicación; 


lugares (por ejemplo: planta de producción o mue- 
lle de carga) que establecenel contexto del problema 
y la función general del sistema; 


estructuras (por ejemplo: sensores, vehículos de cua- 
tro ruedas o computadoras) que definen una clase de 
objetos o, en casos extremos, clases relacionadas de 
objetos. 


iS 


Ocurrencias 
_ 
, [Cosas 4 
Ú 5 Y 
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Y 
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Nombre 
de clase 

AS 


FIGURA 20.9. Cómo se manifiestan los objetos. 


5 En este contexto, el termino suceso denota cualquier ocurrencia. 
No necesariamente implica control, en el sentido del Capítulo 12. 
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La clasificación mostrada anteriormente es una de 
las muchas que se han propuesto en la literatura. 

También es importante destacar.qué no son los obje- 
tos. En general, un objeto nunca debe tener un «nom- 
bre procedimental imperativo» [CAS89]. Por ejemplo, 
si los desarrolladores de un software para un sistema 
gráfico médico definieron un objeto con el nombre 
inversión de imagen, estarían cometiendo un sutil error. 
La imagen obtenida por el software pudiera ser, en efec- 
to, un objeto (es un elemento que forma parte del domi- 
nio de información), pero la inversión de la imagen es 
una operación que se aplica a dicho objeto. Inversión 
debe definirse como una operación del objeto imagen, 
pero no como objeto separado que signifique Szver- 
sión de imagen». Como establece Cashman [CAS89], 
«...el objetivo de la orientación a objetos es encapsular, 
pero manteniendo separados los datos y las operacio- 
nes sobre estos datos». 

Para ilustrar cómo pueden definirse los objetos duran- 
te las primeras etapas del análisis, volvamos al ejemplo 
del sistema de seguridad HogarSeguro. En el Capitulo 
12,realizamos un «análisis sintáctico gramatical» sobre 
la narrativa de procesamiento para el sistema Hogar- 
Seguro. La narrativa de procesamiento se reproduce a 
continuación: 


El software HogarSeguro le permite al propietario de la 
casa configurar el sistema de seguridad una vez que este se 
instala, controla todos los sensores conectados al sistema de 
seguridad, e interactúa con el propietario a través de un tecla- 
do numérico y teclas de función contenidas en el panel de 
control de HogarSeguro mostrado en la Figura 11.2 


Durante la instalación, el panel de control de HogarSe- 
guro seusa para «programar» y configurar el sistema. A cada 
sensor se le asigna un número y tipo, se programa una con- 
traseña maestra para activar y desactivarel sistema, y se intro 
ducen números de teléfono a marcar cuando un sensor detecte 
un suceso. 


Cuando se reconoce un suceso de sensor, el software invo- 
ca una alarma audible asociada al sistema. Después de un 
tiempo de espera especificado por el propietario durante las 
actividades de configuración del sistema, el software marca 
un número de teléfono de un servicio de control, proporcio- 
na información acerca de la localización, e informa de la 
naturaleza del suceso detectado. El número será remarcado 
cada 20 segundos hasta obtener una conexión telefónica. 

Toda la interacción con HogarSeguro está gestionada por 
un subsistema de interacción con el usuario que toma la entra- 
da a partir del teclado numérico y teclas de función, y mues- 
tra mensajes y el estado del sistema en la pantalla LCD. La 
interacción con el teclado toma la siguiente forma... 


a 
a 


CLAVE 


Hay que utilizar un anolizador sintáctico gramatical 
para detectar objetos potenciales (nombres) y 
operaciones (verbos). 
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Extrayendo los nombres podemos proponer varios 


objetos potenciales: 


Clase / Clasificación 
Objeto potencial general 
propietario rol o 

entidad externa 
sensor entidad externa 


panel de control entidad externa 


instalación ocurrencia 


sistema 
(alias sistema 
de seguridad) 


cosa 


número, tipo no son objetos, 


sino atributos de 


Z sensor 
contraseña 
maestra cosa 
número 
de teléfono cosa 
suceso de sensor 
ocurrencia 


alarma audible 


dá entidad externa 
servicio 
de control unidad organizacio- 


nal o entidad 


La lista anterior se continuará hasta que se hayan 
considerado todos los nombres de la descripción del 
proceso. Observe que hemos llamado a cada entrada en 
la lista un objeto potencial. Debemos considerar cada 
uno de ellos antes de tomar una decisión final. 


Cómo saber si un objeto 
potencial es un buen 
candidato para utilizarlo 

en un sistema 00. 


Coad y Yourdon [COA91] sugieren seis caracterís- 
ticas de selección a usar cada vez que un analista con- 
sidera si incluye o no un objeto potencial en el modelo 
de análisis: 

1. Información retenida: el objeto potencial será de 
utilidad durante el análisis solamente si la infor- 
mación acerca de él debe recordarse para que el sis- 
tema funcione. 


2. Servicios necesarios: el objeto potencial debe 
poseer un conjunto de operaciones identificables 
que pueden cambiar de alguna manera el valor de 
sus atributos. 


3. Atributos múltiples: durante el análisis de requisitos, 
se debe centrar la atención en la información princi- 
pal (un objeto con un solo atributo puede, en efecto, 
ser Útil durante el diseño, pero seguramente será 
mejor presentado como un atributo de otro objeto 
durante la actividad de análisis); 
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4. Atributos comunes: puede definirse un conjunto de 
atributos para el objeto potencial, los cuales son apli- 
cables a todas las ocurrencias del objeto. 


3. Operaciones comunes: puede definirse un conjunto 
de operaciones para el objeto potencial, las cuales 
son aplicables a todas las ocurrencias del objeto; 


6. Requisitos esenciales: entidades externas que apa- 
recen en el espacio del problema y producen o con- 
sumen información esencial para la producción de 
cualquier solución para el sistema, serán casi siem- 
pre definidas como objetos en el modelo de requi- 
sitos. 


e, 
CLA VE 


Un objeto potencial debe satistacerla mayoría de estas 
característicaspara utilizarlo en el modelo de análisis. 


Para ser considerado un objeto válido a incluir en 
el modelo de requisitos, un objeto potencial debe satis- 
facer todas (o casi todas) las características anterio- 
res. La decisión de incluir objetos potenciales en el 
modelo de análisis es algo subjetivo, y una evalua- 
ción posterior puede llegar a descartar un objeto o 
reincluirlo. Sin embargo, el primer paso del AOO debe 
ser la definición de objetos, y la consiguiente toma de 
decisiones (incluso subjetivas). Teniendo esto en cuen- 
ta, aplicamos las características selectivas a la lista de 
objetos potenciales de HogarSeguro (véase tabla a 
continuación). 


Clase / Características 

Objeto potencial aplicables 

propietario Rechazado 
(1,2 fallan aunque 
6 es aplicable) 

sensor Aceptado (se aplican 
todas) 

panel de control Aceptado (se aplican 
todas) 

instalación Rechazado 

sistema (alias sis- Aceptado (se aplican 

tema de seguridad) todas) 

número, tipo Rechazado (falla 3) 

contraseña maestra Rechazado (falla 3) 

número de teléfono Rechazado (falla 3) 

suceso de sensor Aceptado (se aplican 
todas) 

alarma audible Aceptado (se aplican 
2, 3, 4, 5Y 6) 

servicio de control Rechazado (fallanl y 


2 aunque 6 se aplica) 
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Debe tenerse en cuenta que: (1) la lista anterior no 
incluye todo, hay que añadir objetos adicionales para com- 
pletar el modelo; (2) algunos de los objetos potenciales 
rechazados serán atributos de los objetos aceptados (por 
ejemplo, número y tipo son atributos de sensor, y con- 
traseña maestra y número de teléfono pueden convertir- 
seen atributos de sistema); y (3) diferentes descripciones 
del problema pueden provocar la toma de diferentes deci- 
siones de «aceptación o rechazo» (por ejemplo, si cada 
propietario tiene su propia contraseña o fue identificado 
por impresiones de voz, el objeto Propietario cumpliría 
las características 1 y 2 y habría sido aceptado). 


20.3.2. Especificación de atributos 


Los atributos describen un objeto que ha sido seleccio- 
nado para ser incluido en el modelo de análisis. En esen- 
cia, son los atributos los que definen al objeto, los que 
clarifican lo que se representa el objeto en el contexto del 
espacio del problema. Por ejemplo, si tratáramos de cons- 
truir un sistema de estadísticas para jugadores profesio- 
nales de béisbol, los atributos del objeto Jugador serían 
muy diferentes de los atributos del mismo objeto cuando 
seuse dentro del contextode un sistema de pensiones para 
jugadores profesionales. En el primero, atributos tales 
como nombre, posición; promedio de bateo, porcentaje 
de estancia en el campo de juego, años jugados y parti- 
dos jugados pueden ser relevantes. En el segundo caso, 
algunos de estos atributos seríanrelevantes pero otros serí- 
an reemplazados (o potenciados)por atributoscomo sala- 
rio medio, crédito total, opciones elegidas para el plan de 
pensión, dirección postal, etc. 

Para desarrollar un conjunto significativo de atributos 
para un objeto, el analista puede estudiar de nuevo la narra- 
tiva del proceso (o descripción del ámbito del alcance) 
para el problema y seleccionar aquellos elementos que 
razonablemente «pertenecen» al objeto. Además, para 
cada objeto debe responderse el siguiente interrogante: 
«¿Qué elementos (compuestos y/o simples) definen com- 
pletamente al objeto en el contexto del problema actual?» 


a 
: CLA VE 


Los atributos se escogen examinando el problema, 
buscando cosas que definan completamente los objetos 
y que los hacen únicos. 


Para ilustrar esto, consideremos el objeto Sistema 
definido para HogarSeguro. Anteriormente ya indica- 
mos que el propietario puede configurar el sistema de 
seguridad para reflejar la información acerca de los sen- 
sores, sobre la respuesta de la alarma, sobre la activa- 
ción/desactivación, sobre identificación, etc. Usando la 
notación de la descripción del contenido definida para 
el diccionario de datos y presentada en el Capítulo 12, 
podríamos representar estos elementos de datos com- 
puestos de la siguiente manera: 
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información del censor = tipo de sensor 
+ número de sensor + umbral de alarma 


información de respuesta de la alarma 
tiempo de retardo + número de teléfono 


+ tipo de alarma 


información de activación/desactivación 
contraseña maestra + Cantidad de 
intentos permitidos + contraseña tempo- 
ral 


información de identificación = ID del 
sistema + verificación de número de telé- 
Eono + estado del sistema 


Cada uno de los elementos de datos a la derecha del 
signo de igualdad puede volver a definirse en un nivel 
elemental, pero para nuestros propósitos, comprenden 
una lista razonable de atributos para el objeto sistema 
(porción sombreada de la Fig. 20.10). 


20.3.3. Definición de operaciones 


Las operaciones definen el comportamiento de un obje- 
to y cambian, de alguna manera, los atributos de dicho 
objeto. Más concretamente, una operación cambia valo- 
res de uno o más atributos contenidos en el objeto. Por 
lo tanto, una operación debe tener «conocimiento» de 
la naturaleza de los atributos de los objetos y deben ser 
implementadas de manera tal que le permita manipular 
las estructuras de datos derivadas de dichos atributos. 
Aunque existen muchos tipos diferentes de opera- 
ciones, éstas pueden clasificarse en tres grandes cate- 
gorías: (1) operaciones que manipulan, de alguna 
manera, datos (p.e.: añadiendo, eliminando, reforma- 
teando, seleccionando); (2) operaciones que realizan 
algún cálculo; y (3) operaciones que monitorizan un 
objeto frente a la ocurrencia de un suceso de control. 


Existe alguna forma 
razonable de categorizar 
las operaciones de un objeto? 


En una primera iteración para obtener un conjunto de 
Operaciones para los objetos del modelo de análisis, el 
analista puede estudiar de nuevo la narrativa del proce- 
so (o descripción del ámbito) del problema y seleccio- 
nar aquellas operaciones que razonablemente pertenecen 
al objeto. Para realizar esto, se estudia de nuevo el aná- 
lisis gramatical y se aíslan los verbos. Algunos de estos 
verbos serán operaciones legítimas y pueden conectar- 
se fácilmente a un objeto específico. Por ejemplo, de la 
narrativa de proceso de Hogarseguro, presentada ante- 
riormente en este capítulo, vemos que cal sensor se le 
asigna un número y un tipo» O que «se programa una 
contraseña maestra para activar y desactivarel sistema». 
Estas dos frases indican varias cosas: 
que una operación de asignación es relevante para 
el objeto Sensor; 
que una operación de programar se le aplicará al 
objeto Sistema; 
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+ que activar y desactivar son operaciones aplicables 
al Sistema (o sea que el estado del sistema puede 
en última instancia definirse usando notación del dic- 
cionario de datos) como 


estado del sistema [activado | desacti- 


vado] 


Tras una investigación más detallada, es probable 
que haya que dividir la operación programar en varias 
suboperaciones más específicas requeridas para con- 
figurar el sistema. Por ejemplo, programar implica 
especificar números de teléfonos, configurar carac- 
terísticas del sistema (por ejemplo, crear la tabla de 
sensores, introducir las características de las alar- 
mas), e introducir la(s) contraseña(s), pero por aho- 
ra, especificaremos programar como una operación 
simple. 


ID del sistema 

Número de teléfono de verificación 
Estado del sistema 

Tabla de sensores 

Tipo de sensor 

Número de sensor 

Umbral de alarma 

Contraseña maestra 

Contraseña temporal 

Número de intentos 


Programar ( ) 
Mostrar ( ) 
Reiniciar ( ) 
Consultar ( ) 
Modificar ( ) 
Llamar ( ) 


FIGURA 20.10. El objeto sistema con operaciones 
asociadas. 


20.3.4. Fin de la definición del objeto 


La definición de operaciones es el Último paso para 
completar la especificación del objeto. En la Sección 
20.3.3. las operaciones se eligieron a partir de un exa- 
men gramatical de la narrativa de proceso del sistema. 
Las operaciones adicionales pueden determinarse con- 
siderando la «historia de la vida» [COA91] de un obje- 
to y los mensajes que se pasan entre objetos definidos 
por el sistema. 

La historia de la vida genérica de un objeto puede 
definirse reconociendo que dicho objeto debe ser crea- 
do, modificado, manipulado o leído de manera diferen- 
te, y posiblemente borrado. Para el objeto Sistema, esto 
puede expandirsepara reflejar actividadesconocidas que 
ocurren durante su vida (en este caso, durante el tiempo 
que HogarSeguro se mantiene operativo). Algunas de 
las operaciones pueden determinarse a partir de comu- 
nicaciones semejantes entre objetos. Por ejemplo, el 
Suceso sensor enviará un mensaje a Sistema para mos- 
trar en pantalla la localización y número del suceso; el 
Panel de control enviará un mensaje de reinicialización 
para actualizar el estado del Sistema (un atributo); la 
Alarma audible enviará un mensaje de consulta, el 
Panel de control enviará un mensaje de modificación 
para cambiar uno o más atributos sin reconfigurarel obje- 
to sistema por completo; el Suceso sensor enviará un 
mensaje para llamar al número(s) de teléfono(s) conte- 
nido(s) en el objeto. Podrán considerarse otros mensa- 
jes para derivar operaciones correspondientes. La 
definición del objeto resultante se muestra en la Figura 
20.10. 

Se usaría un enfoque similar para cada uno de los 
objetos definidos para HogarSeguro. Después de haber 
definido los atributos y operaciones para todos los obje- 
tos especificados hasta este punto, se crearían los ini- 
cios del modelo AOO. En el Capítulo 21 se presenta un 
estudio más detallado del modelo de análisis creado 
como parte del AOO. 


Como examinamos en la Parte Primera y Segunda de 
este libro, la moderna gestión de proyectos de softwa- 
re puede subdividirse en las siguientes actividades: 


1. Establecimiento de un marco de proceso común 
para el proyecto. 


2. Uso del marco y de métricashistóricas para desa- 
rrollar estimaciones de esfuerzo y tiempo. 


3. Especificación de productos de trabajo e hitos que 
permitirán medir el progreso. 


4. Definición de puntos de comprobación para la gestión 
de riesgos, aseguramiento de la calidad y control. 


3. Gestión de los cambios que ocurren invariable- 
mente al progresar el proyecto. 
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6. Seguimiento, monitorización y control del progreso. 


los 


las proyectas 00 requieren mucha más gestión 

de lo planificación y seguimientoque los proyectas 
desoftware convencional. No suponga que la 00 
le releva de esto actividad. 


El director técnico que se enfrenta con un proyecto 
de software orientado a objetos aplica estas seis activi- 
dades. Pero debido a la naturaleza única del software 
orientado a objetos, cada una de estas actividades de 
gestión tiene un matiz levemente diferente y debe ser 
enfocado usando un modelo propio. 
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En las secciones que siguen, exploramos el área de 
gestión de proyectos orientados a objetos. Los princi- 
pios de gestión fundamentales serán los mismos, pero 
para que un proyecto OO sea dirigido correctamente 
hay que adaptar la técnica. 


Referencia 


Encontraráun tutorial muy completo sobre gestión 
de proyectos DO y un buen conjunto de enlaces en: 
mini.net/cetus/oo_project_mngt.html. 


20.4.1. El marco de proceso común para OO 

Un marco de proceso común (MPC) define un enfoque 
organizativo para el desarrollo y mantenimiento de soft- 
ware. El MPC identifica el paradigma de ingeniería del 
software aplicado para construir y mantener el softwa- 
re, asícomo las tareas, hitos y entregas requeridos. Esta- 
blece el grado de rigor con el cual se enfocarán los 
diferentes tipos de proyectos. El MPC siempre es adap- 
table, de tal manera que siempre cumpla con las nece- 
sidades individuales del equipo del proyecto. Ésta es su 
característica más importante. 


Referencia cruzada 


El marco de procesa común define las octividades 
Básicos de ingeniería del software. Se describe 
en el Capítulo 2, 


Ed Berard [BER93] y Grady Booch [BOO91], entre 
otros, sugieren el uso de un «modelo recursivo/parale- 
lo» para el desarrollo de software orientado a objetos. 
En esencia, el modelo recursivo/paralelo funciona de la 
siguiente manera: 

+ Realizar los análisis suficientes para aislar las clases 
del problema y las conexiones más importantes. 

+ Realizar un pequeño diseño para determinar si las 
clases y conexiones pueden ser implementadas de 
manera práctica. 

+. Extraer objetos reutilizables de una biblioteca para 
construir un prototipo previo. 

+ Conducir algunas pruebas para descubrir errores en 
el prototipo. 

+ Obtener realimentación del cliente sobre el proto- 
tipo. 

+ Modificarel modelo de análisis basándose en lo que 
se ha aprendido del prototipo, de la realización del 
diseño y de la realimentación obtenida del cliente. 


+ Refinarel diseño para acomodar sus cambios. 
+ Construir objetos especiales (no disponibles en la 
biblioteca). 
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+ Ensamblar un nuevo prototipo usando objetos de la 
biblioteca y los objetos que se crearon nuevos. 

+ Realizar pruebas para descubrir errores en el proto- 
tipo. 

+. Obtener realimentación del cliente sobre el proto- 
tipo. 
Este enfoque continúa hasta que el prototipo evolu- 

ciona hacia una aplicación en producción. 


¿Cómo aplicar un modelo 
recursivo /paralelo en la 
ingeniería del software 00? 


El modelo recursivo/paralelo es muy similar al mode- 
lo de proceso OO presentado anteriormenteen este capí- 
tulo. El progreso se produce iterativamente.Lo que hace 
diferente al modelo recursivo/paralelo es el reconoci- 
miento de que (1) el modelo de análisis y diseño para 
sistemas OO no puede realizarse a un nivel uniforme 
de abstracción, y (2) el análisis y diseño pueden apli- 
carse a componentes independientes del sistema de 
manera concurrente. Berard [BER93] describe el mode- 
lo de la siguiente manera: 


+. Descomponer sistemáticamenteel problema en com- 
ponentes altamente independientes. 


+. Aplicar de nuevo el proceso de descomposición a 
cada una de las componentes independientes para, a 
su vez, descomponerlas (la parte recursiva). 


+ Conducir este proceso de reaplicar la descomposi- 


ción de forma concurrente sobre todos los compo- 
nentes (la parte paralela). 


+ Continuar este proceso hasta cumplir los criterios de 
finalización. 


Es importante observar que el proceso de descom- 
posición mostrado anteriormente es discontinuo si el 
analista/diseñador reconoce que el componente o sub- 
componente requerido está disponible en una bibliote- 
ca de reutilización. 

Para controlar el marco de proceso recursivo/para- 
lelo, el director del proyecto tiene que reconocer que el 
progreso está planificado y medido de manera incre- 
mental. Esto es, las tareas y la planificación del proyecto 
están unidas a cada una de las «componentes altamen- 
te independientes», y el progreso se mide para cada una 
de estas componentes individualmente. 


Corso 


En muchos aspectos, lo arquitectura de un sistema 00 
hace que el comenzor o trabajar en paralelo sea 

más fácil. Sinembargo, también es cierto que codo 
toreo paralela se define de formo que pueda calcularse 
elprogreso. 
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Análisis 


Revisión y refinamiento 


Análisis Diseño 


Análisis 


Primeras iteraciones 
en análisis/diseño 


Diseño 
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reutilizables 


Planificación 
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Evaluación 
del cliente 


| Revisión y refinamiento 
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reutilizables 


Evaluación 
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FIGURA 20.11. Secuencia típica de un proceso para un proyecto OO. 


Cada iteración del proceso recursivo/paralelo requie- 
re planificación, ingeniería (análisis, diseño, extracción 
de clases, prototipado y pruebas) y actividades de eva- 
luación (Fig. 20.11). Durante la planificación, las activi- 
dades asociadas con cada una de las componentes 
independientes del programa son incluidas en la planifi- 
cación. [Nota: Con cada iteración se ajusta la agenda para 
acomodar los cambios asociados con la iteración prece- 
dente]. Durante las primeras etapas del proceso de inge- 
niería, el análisis y el diseño se realizan iterativamente. 
La intención es identificartodos los elementosimportan- 
tes del análisis OO y de los modelos de diseño. Al conti- 
nuar el trabajo de ingeniería, se producen versiones 
incrementales del software. Durante la evaluación se rea- 
lizan, para cada incremento, revisiones, evaluaciones del 
cliente y pruebas, las cuales producen una realimentación 
que afecta a la siguiente actividad de planificación y al 
subsiguiente incremento. 


20.4.2. Métricas y estimación en proyectos 
orientados a objetos 

Las técnicas de estimación en proyectos de software con- 

vencionales requieren estimaciones de líneas de código 

(LDC) o puntos de función (PF) como controlador prin- 

cipal de estimación. Las estimaciones realizadas a partir 

de LDC tienen poco sentido en proyectos VO debido a 


que el objetivo principal es la reutilización. Las estima- 
ciones a partir de PF pueden usarse de manera efectiva, 
pues los elementos del dominio de información requeri- 
dos se pueden determinar a partir del planteamiento del 
problema. El análisis de PF puede aportar valores para 
estimacionesen proyectos OO,pero la medida de PF no 
provee una granularidad suficiente para ajustes de plani- 
ficación y esfuerzo a realizar, los cuales se requieren cuan- 
do iteramos a través del paradigma recursivo/paralelo. 

Lorenz y Kidd [LOR94] sugieren el siguiente con- 
junto de métricas para proyectos”: 


Número de guiones de escenario. Un guión de 
escenario (como los casos de uso discutidos en el 
Capítulo 11)es una secuencia detallada de pasos que 
describen la interacción entre el usuario y la aplica- 
ción. Cada guión se organiza en tripletes de la forma: 


(iniciador, acción, participante] 


donde iniciador es el objeto que solicita algún ser- 
vicio (que inicia un mensaje); acción es el resultado 
de la solicitud; y participante es el objeto servidor 
que cumple la petición (solicitud). El número de guio- 
nes de actuación está directamente relacionada al 
tamaño de la aplicación y al número de casos de prue- 
ba que se deben desarrollar para ejercitar el sistema 
una vez construido. 


6 Las técnicas de medida de sistemas OO se discuten con detalle en 
el capítulo 24. 
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Consuofh 


Estos métricos pueden utilizarse poro complementar los 
métricos FP. Proporcionanuno formo de «medir» un 
proyecto 00. 


Número de clases clave. Las clases clave son las 
«componentes altamente independientes» [LOR94] 
definidas inicialmente en el AOO. Debido a que estas 
clases son centrales al dominio del problema, el 
número de dichas clases es una indicación del esfuer- 
zo necesario para desarrollar el software y de la can- 
tidad potencial de reutilización a aplicar durante el 
desarrollo del sistema. 


Número de clases de soporte. Las clases de sopor- 
te son necesarias para implementar el sistema, pero no 
están directamente relacionadas con el dominio del 
problema. Como ejemplos podemos tomar las clases 
de Interfaz Gráfica de Usuario, el acceso a bases de 
datos y su manipulación y las clases de comunicación. 
Además las clases de soporte se definen iterativamen- 
te a lo largo del proceso recursivo/paralelo. 


El número de clases de soporte es un indicador 
del esfuerzo necesario requerido para desarrollar 
el software y de la cantidad potencial de reutiliza- 
ción a aplicar durante el desarrollo del sistema. 


Enel Copítulo 24 se presenton detallodamente 
los métricas 00. 


Número promedio de clases de soporte por cla- 
se clave. En general las clases clave son conocidas 
en las primeras etapas del proyecto. Las clases de 
soporte se definen a lo largo de éste. Si, dado un 
dominio de problema, se conociera la cantidad pro- 
medio de clases de soporte por clase clave, la esti- 
mación (basada en la cantidad total de clases) se 
simplificaríamucho. 


Lorenz y Kidd sugieren que las aplicaciones con 
IGU poseen entre dos y tres veces más clases de sopor- 
te que clases clave. Las aplicaciones sin IGU poseen 
alo sumo dos veces más de soporte que clave. 


Número de subsistemas.Un subsistema es una agre- 
gación de clases que dan soporte a una función visible 
al usuario final del sistema. Una vez que se identifican 
los subsistemas, resulta más fácil realizar una planifica- 
ción razonable en la cual el trabajo en los subsistemas 
está repartida entre los miembros del proyecto. 


20.43. Un enfoque OO para estimaciones 
y planificación 
La estimación en proyectos de software es más un arte 


que una ciencia. Sin embargo, esto en modo alguno 
excluye el uso de un enfoque sistemático. Para desa- 
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rrollar estimaciones razonables es esencial el desarro- 
llo de múltiples puntos de datos. Esto significa que las 
estimaciones deben derivarse usando diferentes técni- 
cas. Las estimaciones respecto al esfuerzo y la duración 
usadas en el desarrollo de software convencional (Capí- 
tulo 5 ) son aplicables al mundo de la OO, pero la base 
de datos histórica para proyectos OO es relativamen- 
te pequeña en muchas organizaciones. Debido a esto, 
vale la pena sustituir la estimación de costes para soft- 
ware convencional por un enfoque diseñado explícita- 
mente para software OO. Lorenz y Kidd [LOR94] 
sugieren el siguiente enfoque: 


1, Desarrollo de estimaciones usando la descompo- 
sición de esfuerzos, análisis de PF y cualquier otro 
método aplicable a aplicaciones convencionales. 


Desarrollar guiones de escenario y determinar una 
cuenta, usando AOO (Capítulo 21). Reconocer que 
el número de guiones de escenarios puede cambiar 
con el progreso del proyecto. 


En el Copítulo 5 se consideran diferentes técnicos 
de estimación de proyectos software 


Determinar la cantidad de clases clave usando 
AOO. 


Clasificar el tipo de interfaz para la aplicación y 
desarrollar un multiplicador para las clases de 
soporte: 


Tipo de Interfaz Multiplicador 
En 


(N 


terfaz no gráfica 
o 1GU) 


Interfaz de usuario 
basada en texto 


Interfaz Gráfica de Usario 
(1GU) 


Interfaz Gráfica de Usuario 


(IGU) compleja 3,0 


Multiplicar el número de clases clave (paso 3) por 
el multiplicador anterior para obtener una estima- 
ción del número de clases de soporte. 


Multiplicar la cantidad total de clases (clave + 
soporte) por el número medio de unidades de trabajo 
por clase. Lorenz y Kidd sugierenentre 15y 20 días- 
-persona por clase. 


. Comprobar la estimación respecto a clases multipli- 
cando el número promedio de unidades de trabajo 
por guión de acción. 


La planificación de proyectos orientados a objetos 
es complicada por la naturaleza iterativa del marco de 
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trabajo del proceso. Lorenz y Kidd sugieren un conjunto 
de métricas que pueden ayudar durante esta planifica- 
ción del proyecto: 

Número de iteraciones principales. Recor- 
dando el modelo en espiral (Capítulo 2), una ite- 
ración principal corresponderá a un recorrido de 
360 grados de la espiral. El modelo de proceso 
recursivo/paralelo engendrará un número de mini— 
espirales (iteraciones localizadas) que suceden 
durante el progreso de la iteración principal. Lorenz 
y Kidd sugieren que las iteraciones de entre 2.5 y 
4 meses de duración son más fáciles de seguir y 
gestionar. 

Número de contratos completos. Un contrato 
es «un grupo de responsabilidades públicas rela- 
cionadas que los subsistemas y las clases propor- 
cionan a sus clientes» [LOR94]. Un contrato es un 
hito excelente, y debería asociarse al menos un con- 
trato a cada iteración del proyecto. Unjefe de pro- 
yecto puede usar contratos completos como un 
buen indicador del progreso en un proyecto OO. 


20.4.4. Seguimiento del progreso en un pro- 
yecto orientado a objetos 

Aunque el modelo de proceso recursivo/paralelo es el 
mejor marco de trabajo para un proyecto OO,el para- 
lelismo de tareas dificulta el seguimiento del proyec- 
to. El jefe del proyecto puede tener dificultades 
estableciendo hitos significativos en un proyecto VO 
debido a que siempre hay un cierto número de cosas 
ocurriendo a la vez. En general, los siguientes hitos 
principales pueden considerarse «completados» al 
cumplirse los criterios mostrados: 


Hito técnico: análisis OO terminado 

Todas las clases, y la jerarquía de clases, están defi- 
nidas y revisadas. 

Se han definido y revisado los atributos de clase y 
las operaciones asociadas a una clase. 

Se han establecido y revisado las relaciones entre 
clases (Capítulo 21). 


Se ha creado y revisado un modelo de comporta- 
miento (Capítulo 21). 
Se han marcado clases reutilizables. 


Hito técnico: diseño OO terminado 

Se ha definido y revisado el conjunto de subsistemas 
(Capítulo 22). 

Las clases se han asignado a subsistemas y han sido 
revisadas. 

Se ha establecido y revisado la asignación de tareas. 
Se han identificado responsabilidades y colabora- 
ciones (Capítulo 22). 

Se han diseñado y revisadolos atributosy operaciones. 
Se ha creado y revisado el modelo de paso de men- 
sajes. 


Hito técnico: programación OO terminada 

Cada nueva clase ha sido implementada en código a 
partir del modelo de diseño. 

Las clases extraídas (de una biblioteca de reutiliza- 
ción) se han integrado. 

Se ha construido un prototipo o incremento. 


Hito técnico: prueba OO 

Han sido revisadas la corrección y compleción del 
análisis 00 y del modelo de diseño. 

Se ha desarrollado y revisado una red de clases— 
responsabilidades—colaboraciones (Capítulo 23). 
Se han diseñado casos de prueba y ejecutado prue- 
bas al nivel de clases para cada clase (Capítulo 23). 
Se han diseñado casos de prueba y completado prue- 
bas de agrupamientos (Capítulo 23) y las clases se 
han integrado. 

Se han terminado las pruebas del sistema. 


Recordando el modelo de proceso recursivo/parale- 
lo examinado anteriormente en este capítulo, es impor- 
tante destacar que cada uno de estos hitos puede ser 
revisado nuevamente al entregar diferentes incremen- 
tos al usuario. 


Las tecnologías de objetos reflejan una visión natu- 
ral del mundo. Los objetos se clasifican en clases y 
las clases se organizan en jerarquías. Cada clase con- 
tiene un conjunto de atributos que la describen y un 
conjunto de operaciones que define su comporta- 
miento. Los objetos modelan casi todos los aspectos 
identificables del dominio del problema: entidades 
externas, cosas, ocurrencias, roles, unidades organi- 
zacionales, lugares y estructuras pueden ser repre- 
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sentados como objetos. Es importante destacar que 
los objetos (y las clases de las que se derivan) encap- 
sulan datos y procesos. Las operaciones de procesa- 
miento son parte del objeto y se inician al pasarle un 
mensaje al objeto. Una definición de clase, una vez 
definida, constituye la base para la reutilización en 
los niveles de modelado, diseño e implementación. 
Los objetos nuevos pueden ser instaciados a partir 
de una clase. 


www.elsolucionario.net 


Tres conceptos importantes diferencianel enfoque OO 
de la ingeniería del software convencional. El encapsu- 
lamiento empaqueta datos y las operaciones que mane- 
jan esos datos. La herencia permite que los atributos y 
operaciones de una clase puedan ser heredados por todas 
las clases y objetos que se instancian de ella. El poli- 
morfismo permite que una cantidad de operaciones dife- 
rentes posean el mismo nombre, reduciendo la cantidad 
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de líneas de código necesarias para implementar un sis- 
tema y facilita los cambios en caso de que se produzcan. 

Los productos y sistemas orientadosa objetos se pro- 
ducen usando un modelo evolutivo, a veces llamado 
recursivo/paralelo. El software orientado a objetos evo- 
luciona iterativamente y debe dirigirse teniendo en cuen- 
ta que el producto final se desarrollará a partir de una 
serie de incrementos. 


[BER93] Berard, E.V., Essays on Object—Oriented Softwa- 
re Engineering, Addison — Wesley, 1993. 


[BOO86] Booch, G., «Object-Oriented Development», IEEE 
Trans. Software Engineering, Vol. SE-12,Febrero 1986, 
pp. 211 y ss. 


[BOO91] Booch, G., Object-Oriented Design, Benjamin- 
Cummings, 1991. 


[BUD96] Budd, T., An introduction to Object-Oriented Pro- 
gramming, 2.* ed., Addison-Wesley, 1996. 


[CAS89] Cashman, M., «Object-Oriented Domain Analysis», 
ACM Software Engineering Notes, vol. 14,n.* 6, Octubre 
1989, pp 67. 


[CHA93] Champeaux, D. de D. Lea, y P. Faure, Object-Orien- 
ted System Development, Addison-Wesley, 1993. 


[COA91] Coad, P., y Yourdon, E., Object- Oriented Analysis, 
2." ed., Prentice-Hall, 1991. 


[COX86] Cox, B.J., Object-Oriented Programming, Addi- 
son-Wesley, 1986. 


[EVB89] Object-Oriented Requirements Analysis (course 
notebook), EVB Software Engineering, Inc., Frederick, 
MD, 1989. 


[JAC92] Jacobson, I., Object-Oriented Software Engineering, 
Addison-Wesley, 1992. 


[LOR94] Lorenz, M., y Kidd, J., Object-Oriented Software 
Metrics, Prentice-Hall, 1994. 


[STR88] Stroustrup, B., «What is Object-Oriented Pro- 
gramming?», IEEE Software, vol. 5, n.? 3, Mayo 1988, 
pp. 10-20. 


[TAY90] Taylor, D.A., Object-Oriented Technology:A Mana- 
ger's Guide, Addison-Wesley, 1990. 


20.1. La ingenieríadel software orientada a objetos está reem- 
plazando rápidamente a los enfoques de desarrollo de soft- 
ware tradicionales. Como todas las tecnologías, la orientación 
a objetos también tiene sus fallos. Utilizando Internet y otras 
fuentes de bibliografía más tradicionales, escriba un breve 
artículo que resuma lo que les críticos dicen sobre la OO y 
por qué creen que hay que tener cuidado al aplicar el para- 
digma de objetos. 


20.2. En este capítulo no hemos considerado el caso en el que 
un nuevo objeto necesita un atributo u operación que no está 
contenido en la clase de la que hereda el resto de atributos y 
operaciones. ¿Cómo cree que se manejaría esta situación? 


20.3. Detalle los objetos que participarían en un sistema 
de reservas de vuelos. ¿Cuáles serían sus atributos? 


20.4. Utilizando sus propias palabras y algunos ejemplos defina 
los términos clase, encapsulamiento, herencia y polimorfismo. 


20.5. Revise los objetos definidos en el sistema HogarSe- 
guro. ¿Cree que hay otros objetos que deban ser definidos 
como principio del modelado? 
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20.6. Considere la típica interfaz gráfica de usuario (1GU). 
Defina un conjunto de clases y subclases para las enti- 
dades de la interfaz que aparecen generalmente en una 
IGU. Asegúrese de definir los atributos y operaciones 
apropiadas. 


20.7. Detalle los objetos que aparecerían en un sistema de 
reserva de aulas de lectura en una universidad o colegio. 
¿Cuáles serían sus atributos? 


20.8. Le ha sido asignada la tarea de ingeniería de un nue- 
vo programa de procesamiento de textos. Se ha identifi- 
cado una clase llamada documento. Defina los atributos 
y Operaciones relevantes de dicha clase. 


20.9. Investigue dos lenguajes de programación OO dife- 
rentes y muestre la implementación de los mensajes en la 
sintaxis de cada uno de ellos. Ponga ejemplos. 


20.10. Ponga un ejemplo concreto de reestructuración de 
jerarquía de clases tal y como aparece en la discusión de 
la Figura 20.8. 
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20.11. Ponga un ejemplo de herencia múltiple. Investigue 
algunos artículos sobre el tema y extraiga los pros y los 
contras. 


20.12. Escriba un enunciado para un sistema que le pro- 
porcione su profesor. Utilice el analizador sintáctico gra- 
matical para identificar clases candidatas, atributos y 
Operaciones. Aplique el criterio de selección discutido en 


la Sección 20.3.1 para determinar qué clases deberían estar 
en el modelo de análisis. 


20.13. Describa con sus propias palabras por qué el mode- 
lo recursivo/paralelo es apropiado en los sistemas OO. 


20,14, Ponga tres O cuatro ejemplos de clases clave y de 
soporte que se describieron en la Sección 20.4.2. 


La explosión de interés por las tecnologías OO ha dado como 
resultado la publicación de literalmentecientos de libros duran- 
te los Últimos 15 años. El tratamiento abreviado de Taylor 
[TAY90]sigue siendo la mejor introducción al tema. Además, 
los libros de Ambler (The Object Primer: The application Deve- 
lopper's Guide to Object-Orientation, SIGS Books, 1998), Gos- 
sain y Graham (ObjectModeling and Design Strategies, SIGS 
Books, 1998), Bahar (Object Technology Made Simple, Simple 
Software Publishing, 1996) y Singer(Object Technology Stra- 
tegies and Tactics, Cambndge University Press, 1996)son tam- 
bién valiosas introducciones a los conceptos y métodos OO. 

Zamir (Handbookof Object Technology, CRC Press, 1998) 
ha editado un voluminoso tratado que cubre todos los aspec- 
tos de las tecnologías de objetos. Fayad y Laitnen (Trunsition 
to Object-Oriented Software Development, Wiley, 1998)uti- 
liza casos de estudio para identificar los retos técnicos, cul- 
turales y de gestión a superar cuando una organización hace 
una transición a la tecnología de objetos. Gardner et al. (Cog- 
nitive Patterns: Problems-Solving Frameworks for Object 
Technology, Cambride University Press, 1998)proporcionar 
al lector una introducción básica sobre conceptos de resolu- 
ción de problemas y la tecnología asociada a los patrones cog- 
nitivos y al modelado cognitivo tal y como se aplican en los 
sistemas orientados a objetos. 
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La naturaleza Única del paradigma OO supone especia- 
les retos a los gestores de proyecto. Los libros de Cock- 
Burn (Surviving Object-Oriented Projects: A Manager?s 
Guide, Addison-Wesley, 1998), Booch (Object Solutions: 
Managing the Object Oriented Project, Addison-Wesley, 
1995), Goldberg y Rubin (Succeding With Objects: Deci- 
sion Frameworks for Project Management, Addison-Wes- 
ley, 1995) y Meyer (Object-Success: A Manager”s Guide 
to Object Orientation, Prentice-Hall, 1995) consideran las 
estrategias de planificación, seguimiento y control de pro- 
yectos OO. 

Earles y Simms (Building Business Objects, Wiley, 
1998), Carmichael (Developing Business Objects, SIGS 
Books, 1998), Fingar (The Blueprintfor Business Objects, 
Cambridge University Press, 1996) y Taylor (Business Engi- 
neerin with Object Technology, Wiley, 1995) enfocan la 
tecnología de objetos tal y como se aplica en contextos de 
negocios. Sus libros muestran métodos para expresar los 
conceptos y requisitos de negocio directamente como obje- 
tos y aplicaciones orientadas a objetos. 

En Internet hay gran variedad de fuentes de informa- 
ción sobre tecnologías de objetos y otros temas relaciona- 
dos. En http://www.pressman5.com encontrará una lista 
de referencias web actualizada sobre temas OO. 
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ANÁLISIS ORIENTADO A OBJETOS 


UUANDO se tiene que construir un nuevo producto o sistema, ¿cómo lo caracterizamos de 

forma tal que sea tratado por la ingeniería del software orientado a objetos? ¿Hay pregun- 

tas especiales que queramos hacer al cliente? ¿Cuáles son los objetos relevantes? ¿Cómo 
se relacionan entre sí? ¿Cómo se comportan los objetos en el contexto del sistema? ¿Cómo espe- 
cificamos o modelamos un problema de forma tal que podamos crear un diseño eficaz? 

A cada una de estas interrogantes se responde dentro del contexto del análisis orientado a 
objetos (ADO), primera actividad técnica que se desarrolla como parte de la ingeniería del soft- 
ware OO. En lugar de examinar un problema utilizando el modelo de información clásico de 
flujo de datos, el AOO introduce varios conceptos nuevos. Coad y Yourdon [COA91] conside- 
ran el tema cuando escriben: 


El AOO (Análisis Orientado a Objetos) se basa en conceptos que ya aprendimos en la guardería: obje- 
tos y atributos, clases y miembros, todos y partes. El porqué nos ha llevado tanto tiempo aplicar estos con- 
ceptos al análisis y especificación de sistemas es algo que nadie sabe a ciencia cierta... 


El AOO se basa en un conjunto de principios básicos que se introdujeron en el Capítulo 11. 
Para construir un modelo de análisis se aplican cinco principios básicos: (1) se modela el domi- 
nio de la información; (2) se describe la función; (3) se representa el comportamiento del mode- 
lo; (4) los modelos de datos, funcional y de comportamiento se dividen para mostrar más detalles; 
y (5)los modelos iniciales representan la esencia del problema mientras que los Últimos apor: 
tan'detalles de la implementación. Estos principios forman la base para el enfoque del ADO 
presentado en ese capítulo. 


VISTAZO RÁPIDO 


¿Qué es? Antes de que pueda construirun ¿Por qué es importante? No se puede traslada la información del 


sistema orientado a objetos, tiene que 
definir las clases (obietos) que represen- 
tan el problema a resolver, la forma en 
que las clases se relacionan e interac- 
túan unas con otras, el funcionamiento 
interno (atributosy operaciones) de los 
objetos y los mecanismos de comunica- 
ción (mensajes)que los permiten traba- 
3r juntos. Todasestas cosas secumplen 
en elanálisis orientado a objetos. 


¿Quién lo hace? La definición de un mode- 


lo de análisis lleva implícita una des- 
cripción de las características de las 
clases que describan un sistema o pro- 
ducto. La actividad larealiiun inge- 
niero del software. 


construir software (orientadoa objetos o 
de otro tipo) hasta que setiene un c cono— 
cimiento razonable del sistema o pro- 
ducto. El AOO nos proporciona una forma 
concreta de representar el conocimientó 
de los requisitos y una forma de probar 
dicho conocimientoentrentándolo con la 
percepción que el cliente tiene del siste- 
ma a amstruir. 


¿Cuáles son los pasos? El ADO comien- 


za con una descripción de casos de uso, 
que es una descripción de escenarios 
sobre cómo interactúan los actores (gen- 
te, máquinas u otrossistemas) conel sis- 
tema a construir. El modelo de clases- 
responsabilidad-colaboración (CRC) 


crea un modelo de análisis orientado 
a objetos. Dicho modelo se compone de: 
una representación gráfica, o basada” 
en el lenguaje, que define los atributos 
de la clase, las relaciones y comporta» 
mientos y las comunicaciones entre 
clases, así como una representación 
del comportamiento de la clase en el - 
tiempo. 


El propósito del AOO es definir todas las clases que son relevantes al problema que se va a 
resolver, las operaciones y atributos asociados, las relaciones y comportamientos asociadas con 
ellas. Para cumplirlo se deben ejecutar las siguientes tareas: 

1. Los requisitos básicos del usuario deben comunicarse entre el cliente y el ingeniero del 

software. 

2. Identificar las clases (es decir, definir atributos y métodos). 

3. Se debe especificar una jerarquía de clases. 

4. Representan las relaciones objeto a objeto (conexiones de objetos). 

5. Modelar el comportamiento del objeto. 

6. Repetir iterativamente las tareas de la 1 a la 5 hasta completar el modelo. 
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Es importante observar que no existe un acuerdo universal sobre los «conceptos»que sirven de base para el AOO, 
pero un limitado número de ideas clave se repten a menudo, y son éstas las que consideraremosen este capítulo. 


El objetivo del análisis orientado a objetos es desarro- 
llar una serie de modelos que describan el software de 
computadora al trabajar para satisfacer un conjunto de 
requisitos definidos por el cliente. El AOO, como los 
métodos de análisis convencional descritos en el Capí- 
tulo 12, forman un modelo de análisis multiparte para 
satisfacer este objetivo. El modelo de análisis ilustra 
información, funcionamiento y comportamiento dentro 
del contexto de los elementos del modelo de objetos 
descrito en el Capítulo 20. 


21.1.1. Enfoques convencionales y enfoques OO 


¿Es el análisis orientado a objetos realmente diferente del 
enfoque del análisis estructuradopresentado en el Capí- 
tulo 12? Aunque el debate continúa, Fichman y Keme- 
rer [FIC92] responden a la pregunta directamente: 
Concluimos que el enfoque del análisis orientado a obje- 
tos... representa un cambioradical sobre las metodologíasorien- 
tadas a procesos, tales comoel análisis estructurado, pero sólo 
un cambio incremental respecto a las metodologías orientadas 
a datos, tales como la ingeniería de la información. Las meto- 
dologías orientadas a procesos desvían la atención de las prio- 
ridades inherentesa los objetos durante el proceso de modelado 
y conducen a un modelo del dominio del problema ortogonal 
con los tres principios esenciales de la orientación a objetos: 
encapsulamiento, clasificaciónde objetos y herencia. 


Dicho simplemente, el análisis estructuradotoma una 
visión diferente de los requisitos del modelo entrada- 
proceso-salida. Los datos se consideran separadamente 
de los procesos que los transforman. El comportamien- 
to del sistema, aunque importante, tiende a desempeñar 
un papel secundario en el análisis estructurado. El aná- 
lisis estructurado hace un fuerte uso de la descomposi- 
ción funcional (partición del diagrama de flujo de datos, 
Capítulo 12). 


21.1.2. El panorama del A00O 


La popularidad de las tecnologías de objetos ha gene- 
rado docenas de métodos de AOO desde finales de los 
80 y durante los 90'. Cada uno de ellos introduce un 
proceso para el análisis de un producto o sistema, un 
conjunto de modelos que evoluciona fuera del proceso, 
y una notación que posibilita al ingeniero del software 
crear cada modelo de una manera consistente. Entre los 
más ampliamente utilizados se encuentran": 


La discusión detallada de estos métodos y sus diferencias esta fuera 
del alcance en este libro. Además, la industria se mueve hacia una 
forma de modelado unificada en un único método, lo que hace que 
las discusiones sobre los antiguos métodos sólo tengan sentido a 
efectos históricos. El lector interesado puede consultar a Berard 
[BER92] y Graham (GRA94] para una comparación más detallada. 
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El método de Booch. El método de Booch [BOO94] 
abarca un «microproceso de desarrollo» y un «macro- 
proceso de desarrollo». El nivel micro define un conjunto 
de tareas de análisis que se reaplican en cada etapa en el 
macro proceso. Por esto se mantienen un enfoque evo- 
lutivo. El micro proceso de desarrollo identifica clases y 
objetos y la semántica de dichas clases y objetos, define 
las relaciones entre clases y objetos y realiza una serie de 
refinamientos para elaborar el modelo del análisis. 


: |trabojo con objetos 
de progromación como 


El método de Rumbaugh. Rumbaugh [RUM91] y 
sus colegas desarrollaron la Técnica de Modelado de 
Objetos (OMT) para el análisis, diseño del sistema y 
diseño a nivel de objetos. La actividad de análisis crea 
tres modelos: el modelo de objetos (una representación 
de objetos, clases, jerarquías y relaciones), el modelo 
dinámico (una representación del comportamiento del 
sistema y los objetos) y el modelo funcional (una repre- 
sentación a alto nivel del flujo de información a través 
del sistema similar al DFD). 

El método de Jacobson. También llamado OOSE 
(en español Ingeniería del Software Orientada a Obje- 
tos), el método de Jacobson [JAC92] es una versión sim- 
plificada de Objectory, un método patentado, también 
desarrollado por Jacobson. Este método se diferenciade 
los otros por la importancia que da al caso de uso-una 
descripción o escenario que describe cómo el usuario 
interactúa con el producto o sistema—. 

El método de Coad y Yourdon. El método de Coad 
y Yourdon [COA91] se considera, con frecuencia, como 
uno de los métodos del AVO más sencillos de apren- 
der. La notación del modelado es relativamente simple 
y las reglas para desarrollar el modelo de análisis son 
evidentes. A continuación sigue una descripción resu- 
mida del proceso de AOO de Coad y Yourdon: 
Identificar objetos,usando el criterio de «qué buscar». 
Definir una estructura de generalización-especifi- 
cación. 


2 En general, los métodos de ADO se identifican usando el (olos) 
nombre(s) del desarrollador del método, incluso si al método se le 
ha dado un nombre o acrónimo único 
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Definir una estructura de todo-parte. 

Identificar temas (representaciones de componentes 
de subsistemas). 

Definir atributos. 

Definir servicios. 


El método de Wirfs-Brock. El método de Wirfs- 
Brock [WIR90] no hace una distinción clara entre las 
tareas de análisis y diseño. En su lugar, propone un pro- 
ceso continuo que comienza con la valoración de una 
especificación del cliente y termina con el diseño. A 
continuación se esbozan brevemente las tareas relacio- 
nadas con el análisis de Wirfs-Brock: 

Evaluar la especificación del cliente. 

Usar un análisis gramatical para extraer clases can- 
didatas de la especificación. 

Agrupar las clases en un intento de determinar super- 
clases. 

Definir responsabilidades para cada clase. 

Asignar responsabilidades a cada clase. 

Identificar relaciones entre clases. 

Definir colaboraciones entre clases basándose en sus 
responsabilidades. 

Construir representacionesjerárquicas de clases para 
mostrar relaciones de herencia. 

Construir un grafo de colaboracionespara el sistema. 


Aunque la terminología y etapas del proceso para cada 
uno de estos métodos de AOO difieren, los procesos gene- 
rales de AOO son en realidad muy similares. Para reali- 
zar un análisis orientado a objetos, un ingeniero del 
software debería ejecutar las siguientes etapas genéricas: 
1. Obtener los requisitos del cliente para el sistema. 

2. Identificarescenarios o casos de uso. 

3. Seleccionar clases y objetos usando los requisitos 
básicos como guías. 

4. Identificar atributos y operaciones para cada objeto 
del sistema. 

5. Definir estructuras y jerarquías que organicen las 
clases. 

6. Construir un modelo objeto-relación. 

7. Construir un modelo objeto-comportamiento. 

8. Revisar el modelo de análisis VO con relación a los 
casos de uso/escenarios. 


Estas etapas genéricas se tratan en mayor detalle en 
las Secciones 21.3 y 21.4. 


a 
a 


CLAVE 


Durante el ADO se aplico un conjunto genérico de pasos, 
independientemente del método de análisis elegido. 


3 Booch, Rumbaugh y Jacobson han publicado una trilogía funda- 
mental de libros sobre UML . El lector interesado puede consultar 
[BO0O99], [RUM99] y JAC99]. 
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CAPITULO 21 ANÁLISIS ORIENTADO A OBJETOS 


21.1.3. Un enfoque unificado para el AQO 


Al final de la pasada década, Grady Booch, James Rum- 
baugh e Ivar Jacobson empezaron a colaborar para com- 
binar y recopilar las mejores características de cada uno 
de sus métodos de diseño y análisis orientado a objetos 
en un método unificado. El resultado, denominado Len- 
guaje de Modelado Unificado (UML), se ha convertido 
en el método más utilizado por la industria?. 


nos de los notaciones 
o así un único punto de referencia 


Os importantes. 


UML permite a un ingeniero del software expresar 
un modelo de análisis utilizando una notación de mode- 
lado con unas reglas sintácticas, semánticas y prácticas. 
Eriksson y Penker [ERI98] definen dichas reglas de la 
siguiente forma:, 

La sintaxis nos dice cómo mostrar y combinar los sím- 
bolos. La sintaxis es comparable a las palabras en el lenguaje 
natural: es importante saber cómo se escriben y cómo com- 
binarlas correctamente para formar una frase. Las regias 
semánticas nos dicen lo que significa cada símbolo y cómo 
interpretarlo, tanto cuando aparece solo como cuando lo hace 
en combinación con otros. Es comparable al significado de 
las palabras en el lenguaje natural. 


Las reglas prácticas definen el significado de los símbolos 
a través de los cuales se obtiene el modelo y se hace com- 
prensible para otras personas. Esto correspondería, en lengua- 
je natural, a las regias de construcción de frases claras y 
fácilmente comprensibles. 


En UML, un sistema viene representado por cinco 
vistas diferentes que lo describen desde diferentes pers- 
pectivas. Cada vista se representa mediante un conjun- 
to de diagramas. En UML están presentes las siguientes 
vistas [ALH98]: 


Vista del usuario. Representa el sistema (producto) 
desde la perspectiva de los usuarios (llamados actores 
en UML). El caso de uso es el enfoque elegido para 
modelar esta vista. Esta importante representación del 
análisis, que describe un escenario de uso desde la pers- 
pectiva del usuario final, se describió en el capítulo 111, 


Vista estructural: los datos y la funcionalidad se 


muestran desde dentro del sistema, es decir, modela la 
estructura estática (clases, objetos y relaciones). 


Cionsuof) 


Como en todos los enfoques de análisis, lo obtención 
de requisitos es lo clave. Asegúrese de que obtiene 
lo vista correcta del usuario. El resto saldrá solo. 


* Si aún no lo ha hecho, lea por favor la discusión sobre los casos de 
uso de la Sección 11.2.4. 
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Vista del comportamiento: esta parte del modelo del 
análisis representa los aspectos dinámicos o de com- 
portamiento del sistema. También muestra las interac- 
ciones o colaboraciones entre los diversos elementos 
estructurales descritos en las vistas anteriores. 


Referencia Web 


Enmini.net/cetus/oo_uml.html hay un amplio 
tutorial y una lista de recursos UML que incluye 
herramientas, ortículos y ejemplos. 


Vista de implementación: los aspectos estructurales 
y de comportamientose representan aquí tal y como van 
a ser implementados. 


Vista del entorno: aspectos estructurales y de com- 
portamiento en el que el sistema a implementar se repre- 
senta. 


En general, el modelo de análisis de UML se centra 
en las vistas del usuario y estructural. El modelo de dise- 
ño de UML (tratado en el Capítulo 22) se dirige más a 
las vistas del comportamiento y del entorno. En el Capí- 
tulo 22 describiremos UML con más detalle. 


El análisis en sistemas orientados a objetos puede ocu- 
rrir a muchos niveles diferentes de abstracción. A nivel 


de negocios o empresas, las técnicas asociadas con el 
AOO pueden acoplarse con un enfoque de ingeniería 
de la información (Capítulo 10)en un esfuerzo por defi- 
nir clases, objetos, relaciones y comportamientos que 
modelen el negocio por completo. A nivel de áreas de 
negocios, puede definirse un modelo de objetos que des- 
criba el trabajo de un área específicade negocios (o una 
categoría de productos o sistemas). A nivel de las apli- 
caciones, el modelo de objetos se centra en los requisi- 
tos específicos del cliente, pues éstos afectan a la 
aplicación que se va a construir. 


Y] 
ER 
CLAVE 
El objetivodelanálisis del dominio es definir el conjunto 


declases (objetos) que se encuentran en el dominiode 
la aplicación. Dichas clases poaránreutilizarse muchas veces. 


El AOO, en su nivel de abstracción más alto (el nivel 
de empresa), está más allá del alcance de este libro. Los 
lectores interesados deberían ver a [EEL98], [CAR98], 
[FIN96], [MAT94], [SUL94] y [TAY95], los cuales 
hacen un análisis más detallado. A nivel de abstracción 
más bajo, el AOO cae dentro del alcance general de la 
ingeniería del software orientado a objetos y es el cen- 
tro de atención del resto de las secciones de este capí- 
tulo. En esta sección nos centraremos en el AOO que 
se realiza a un nivel medio de abstracción. Esta activi- 
dad, llamada análisis del dominio, tiene lugar cuando 
una organización desea crear una biblioteca de clases 
reutilizables (componentes) ampliamente aplicables a 
una categoría completa de aplicaciones. 


21.2.1. Análisis de reutilización y del dominio 

Las tecnologías de objetos están influenciadas por la 
reutilización. Considere un ejemplo simple. El análi- 
sis de los requisitos para nuevas aplicaciones indican 


la necesidad de 100 clases. Se le asigna a dos equipos 
la tarea de construir la aplicación. Cada uno debe dise- 
ñar y construir un producto final y, a su vez, está com- 
puesto de personas con el mismo nivel de habilidad y 
experiencia. 


Ronsuof) 


Otrosbeneticiosderivados dela reutilización son 

lo consistencio y la familiaridad. los patrones dentro 
delsofhware serán más consistentes, tendiendo 

o facilitar el mantenimiento delproducto. Asegúrese de 
establecer un conjunto dereglos dereutilización 

poro conseguir dichos objetivos. 


El equipo A no tiene acceso a una biblioteca de cla- 
ses, por lo que debe desarrollar las 100 clases desde 
el principio. El equipo B usa una biblioteca de clases 
robusta y encuentra que ya existen 55 clases. Seguro 
que: 


1. El equipo B finalizará el proyecto mucho antes que 
el A. 

2. El coste del producto del equipo B será significati- 
vamente más bajo que el coste del producto del 
equipo A. 

3. La versión que se distribuya del producto producido 
por el equipo B tendrá menos defectos que la del pro- 
ducto del equipo A. 


Aunque el margen por el cual el trabajo del equipo 
B excederá al del A está abierto a debate, pocos argu- 
mentarán que la reusabilidad aporta una ventaja subs- 
tancial al equipo B. 


¿Pero de dónde vino la «biblioteca de clases robus- 
ta»? ¿Y cómo se determinó que las entradas de la biblio- 
teca eran apropiadas para su uso en nuevas aplicaciones? 
Para responder estas preguntas, la organización que creó 
y mantuvo dicha biblioteca tuvo que aplicar el análisis 
del dominio. 
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21.2.2. El proceso de análisis del dominio 


Firesmith [FIR93] describe el análisis del dominio del 
software de la siguiente manera: 

El análisis del dominio del software es la identificación, 
análisis y especificación de requisitos comunes de un domi- 
nio de aplicación específico, normalmente para su reutili- 
zación en múltiples proyectos dentro del mismo dominio 
de aplicación ... (el análisis orientado a objetos del domi- 
nio es la identificación, análisis y especificación de capa- 
cidades comunes y reutilizables dentro de un dominio de 
aplicación específico, en términos de objetos, clases, sub- 
montajes y marcos de trabajo comunes... 


El «dominio de aplicaciones específico» puede 
variar desde aviónica hasta banca, desde juegos de 
vídeo multimedia hasta aplicaciones dentro de un escá- 
ner CAT. El objetivo del análisis del dominio es cla- 
ro: encontrar o crear aquellas clases ampliamente 
aplicadas, de tal manera que sean reutilizables. 


Le reutilización es la piedra ongular de lo ingeniería 
del software basada -en componentes, tema que se 
aborda en el Capítulo 27. 


Usando la terminología introducida al inicio del 
libro, el análisis del dominio puede verse como la acti- 
vidad de cobertura para el proceso del software. Con 
esto queremos decir que el análisis del dominio es una 
actividad en curso de la ingeniería del software no 
ligada a ningún proyecto de software. En cierta for- 
ma, el papel de un análisis del dominio es similar al 
de un maestro tornero dentro de un entorno de fabri- 
cación fuerte. El trabajo del maestro tornero es dise- 
ñar y construir herramientas que pueden usarse por 
varias personas que trabajan en aplicaciones simila- 
res, pero no necesariamente idénticas. El papel del 
analista del dominio es diseñar y construir compo- 
nentes reutilizables que puedan ser utilizados por dife- 
rentes personas que trabajan en aplicaciones similares 
pero no necesariamente iguales. 


Literatura técnica 


Aplicaciones existentes 


Fuentes 


” Modelo 
de . Recursos del cliente Análisis . del 

domimio del dominio Modelos funcionales análisis 
del Consejo de experto i 5 del 

onocimiento Lenguajes del dominio deminia 


Requisitos actuales/futuros 


FIGURA 21.1. Entrada y salida para análisis del dominio. 
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WAFILUAS Li 


hacer una inversión 


La Figura 21.1 [ARA89] ilustra las entradas y sali- 
das clave para el proceso de análisis del dominio. Se exa- 
minan las fuentes del dominio de conocimiento en un 
intento de identificar objetos que se puedan reutilizar a 
lo largo de todo el dominio. En esencia el análisis del 
dominio es muy similar a la ingeniería del conocimien- 
to. El ingeniero del conocimiento investiga un área de 
interés específica, intentando extraer hechos claves que 
se puedan usar para la construcción de un sistema exper- 
to o una red neuronal artificial. Durante el análisis del 
dominio ocurre la extracción de objetos (y clases). 


Definir el dominio a investigar. Para llevar a cabo 
esta tarea, el analistadebe primero aislarel área de nego- 
cio, tipo de sistema o categoría del producto de interés. 
A continuación, se deben extraer los «elementos» tanto 
00 como no OO. Los elementos OO incluyen especifi- 
caciones, diseños y código para clases de aplicaciones 
00 ya existentes; clases de soporte(p.e.: clases de Inter- 
faz Gráfica de Usuario o clases de acceso a bases de 
datos); bibliotecas de componentes comerciales ya desa- 
rrolladas (CY D) relevantes al dominio y casos de prueba. 
Los elementos no OO abarcan políticas, procedimien- 
tos, planes, estándares y guías; partes de aplicacionesno 
00 (incluyendo especificación, diseño e información de 
prueba), métricas y CYD del software no OO. 


Clasificar los elementos extraídos del dominio. Los 
elementos se organizan en categorías y se establecen las 
características generales que definen la categoría. Se 
propone un esquema de clasificación para las catego- 
rías y se definen convenciones para la nomenclatura de 
cada elemento. Se establecenjerarquías de clasificación 
en caso de ser apropiado. 


Taxonomía de clases 


Estándar de reusabilidad 
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Una estrategia completa del modelo del 
«considesor tanto la arquitectura como los col 
En el Capítulo 14 hoy una completa di 
la ouec delsfvar. 


Recolectar una muestra representativa de aplica- 
ciones en el dominio. Para realizar esta tarea, el ana- 
lista debe asegurar que la aplicación en cuestión tiene 
elementos que caen dentro de las categorías ya defini- 
das. Berard [BER93] observa que durante las primeras 
etapas de uso de las tecnologías de objetos, una orga- 
nización del software tendrá muy pocas, si hay alguna, 
aplicaciones OO. Debido a esto, el analista de dominio 
debe «identificar los objetos conceptuales (opuestos a 
los físicos) en cada aplicación [no 0O]». 


Analizar cada aplicación dentro de la muestra. El 
analista debe seguir las etapas siguientes [BER93]: 


Identificar objetos candidatos reutilizables. 


Indicar las razones que hacen que el objeto haya sido 
identificado como reutilizable. 

Definir adaptaciones al objeto que también pueden 
ser reutilizables. 

Estimar el porcentaje de aplicaciones en el dominio 
que pueden reutilizar el objeto. 

Identificar los objetos por nombre y usar técnicas de 
gestión de configuración para controlarlos (Capítulo 9). 


Además, una vez que se han definido los objetos, el 
analista debe estimar qué porcentaje de una aplicación 
típica pudiera construirse usando los objetos reutilizables. 


Desarrollar un modelo de análisis para los obje- 
tos. El modelo de análisis servirá como base para el 
diseño y construcción de los objetos del dominio. 


Adicionalmente a estas etapas, el analista del domi- 
nio también debe crear un conjunto de líneas maestras 
para la reutilización, y desarrollar un ejemplo que ilus- 
tre cómo los objetos del dominio pudieran usarse para 
crear una aplicación nueva. 

El análisis del dominio es la primera actividad téc- 
nica en una amplia disciplina que algunos llaman inge- 
niería del dominio. Cuando un negocio, sistema O 
producto del dominio es definido como estratégico a 
largo plazo, puede desarrollarse un esfuerzo continua- 
do para crear una biblioteca reutilizablerobusta. El obje- 
tivo es ser capaz de crear software dentro del dominio 
con un alto porcentaje de componentes reutilizables. 
Argumentos a favor de un esfuerzo dedicado a la inge- 
niería del dominio son: bajo coste, mayor calidad y 
menor tiempo de comercialización. 


Referencia 


En www.sei.cmu.edu/ str / descriptions /deda.html 
hoy un tutorial sobre análisis del dominio que merece la peno. 


El proceso de análisis orientado a objetos se adapta a 
conceptos y principios básicos de análisis discutidos en 
el Capítulo 11. Aunque la terminología, notación y acti- 
vidades difieren respecto de los usados en métodos con- 
vencionales, el AVO (en su núcleo) resuelve los mismos 
objetivos subyacentes. Rumbaugh [RUM91] examina 
esto cuando asegura que: 


El análisis... se ocupa de proyectar un modelo preciso, con- 
ciso, comprensible y correcto del mundo real. ...El propósito 
de análisis Orientadoa objetoses modelar el mundo real de for- 
ma tal que sea comprensible. Para esto se deben examinar los 
requisitos, analizar las implicacionesque se deriven de ellos y 
reafirmarlos de manerarigurosa. Sedeben abstraer primero las 
características del mundo real y dejar los pequeños detalles 
para más tarde. 


Para desarrollar un «modelo preciso, conciso, com- 
prensible y correcto del mundo real», un ingeniero del 
software debe seleccionar una notación que se sopor- 
te a un conjunto de componentes genéricos de AOO. 
Monarchi y Puhr [MON92] definen un conjunto de 
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componentes de representación genéricos que apare- 
cen en todos los modelos de análisis OO?. Los compo- 
nentes estáticos son estructurales por naturaleza, e 
indican características que se mantienen durante toda 
la vida operativa de una aplicación. Los componentes 
dinámicos se centran en el control, y son sensibles al 
tiempo y al tratamiento de sucesos. Estos últimos defi- 
nen cómo interactúa un objeto con otros a lo largo del 
tiempo. Pueden identificarse los siguientes componen- 
tes [MON92]: 


Vistaestática de clases semánticas. Una taxonomía de 
clases típicas se mostró en el Capítulo 20. Se imponen los 
requisitos y se extraen (y representan) las clases como 
parte del modelo de análisis. Estas clases persisten a tra- 
vés de todo el período de vida de la aplicación y se deri- 
van basándose en la semántica de los requisitos del cliente. 

2 ¿Cuáles son los componentes 
clave de un modelo de ADO? 


5 Los autores [MON92] aportan también un análisis de veintitrés méto- 
dos de AOO e indican cómo representan éstos dichas componentes. 
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Los componentes estáticos no cambian mientras 


la aplicación se está ejecutando. las componentes 
dinámicos están influenciadospor el tiempo y los sucesos. 


Vista estática de los atributos. Toda clase debe des- 
cribirse explícitamente. Los atributos asociados con la 
clase aportan una descripción de la clase, así como una 
indicación inicial de las operaciones relevantes a esta 
clase. 

Vista estática de las relaciones. Los objetos están 
«conectados» unos a otros de varias formas. El modelo 
de análisis debe representar las relaciones de manera tal 
que puedan identificarse las operaciones (que afecten a 
estas conexiones) y que pueda desarrollarse un buen 
diseño de intercambio de mensajes. 

Vista estática de los comportamientos. Las relacio- 
nes indicadas anteriormente definen un conjunto de com- 
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portamientos que se adaptan al escenario utilizado (casos 
de uso) del sistema. Estos comportamientos se imple- 
mentan a través de la definición de una secuencia de 
Operaciones que los ejecutan. 


Vista dinámica de la comunicación. Los objetos 
deben comunicarse unos con otros y hacerlo basándose 
en una serie de mensajes que provoquen transiciones de 
un estado a otro del sistema. 


Vista dinámica del control y manejo del tiempo. Debe 
describirse la naturaleza y duración de los sucesos que 
provocan transiciones de estados. 


De Champeaux y sus colegas [CHA93] definen una 
vista ligeramente diferente de las representaciones del 
AOO. Las componentes estáticas y dinámicas se 
identifican para el objeto internamente y para las 
representaciones entre objetos. Una vista dinámica e 
interna del objeto puede caracterizarse como la historia 
de vida del objeto, esto es, los estados que alcanza el 
objeto a lo largo del tiempo, al realizarse una serie de 
operaciones sobre sus atributos. 


El proceso de AOO no comienza con una preocupación 
por los objetos. Más bien comienza con una compren- 
sión de la manera en la que se usará el sistema: por las 
personas, si el sistema es de interacción con el hombre; 
por otras máquinas, si el sistema está envuelto en un 
control de procesos; O por otros programas; si el siste- 
ma coordina y controla otras aplicaciones. Una vez que 
se ha definido el escenario, comienza el modelado del 
software. 

Las secciones que siguen definen una serie de técni- 
cas que pueden usarse para recopilar requisitos básicos 
del usuario y después definen un modelo de análisis para 
un sistema orientado a objetos. 


21.41. Casos de uso 


Como examinamos en el Capítulo 11, los casos de uso 

modelan el sistema desde el punto de vista del usuario. 

Creados durante la obtención de requisitos, los casos de 

uso deben cumplir los siguientes objetivos: 

« definir los requisitos funcionales y operativos del sis- 
tema (producto), diseñando un escenario de uso acor- 
dado por el usuario final, y el equipo de desarrollo; 
proporcionar una descripción clara y sin ambigiie- 
dades de cómo el usuario final interactúa con el sis- 
tema y viceversa, y 


Referencia cruzada 


los casos de usa son una excelente herramienta de 
licitoción: de requisitos, independientemente del método de 
onólisis utilizado. Véose el copítulo 11 pora más detalle. 
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proporcionar una base para la validación de las 
pruebas. 


Durante el ADO los casos de uso sirven como base 
para los primeros elementos del modelo de análisis. 

Utilizando UML se puede crear una representación 
visual de los casos de uso llamada diagrama de casos 
de uso. Como otros elementos del análisis, los casos de 
uso pueden representarse a diferentes niveles de abs- 
tracción. Los diagramas de casos de uso contienen casos 
de uso y actores, siendo estos últimos las entidades que 
interactúan con el sistema. Pueden ser humanos u otras 
máquinas o sistemas que tengan definidas interfaces con 
nuestro sistema. 


Referencia 


En www.univ-paris 1.fr /CRINFO /dmrg/MEE/misop014 
existe un tutorial que aborda en profundidad los casos de uso. 


El sistema de seguridad HogarSeguro, discutido en 
capítulos anteriores, puede usarse para ilustrar cómo pue- 
den desarrollarse casos de uso. Recordando los requisi- 
tos básicos de HogarSeguro, podemos definir tres 
actores: el propietario (el usuario), los sensores (dis- 
positivos adjuntos al sistema) y el subsistema de moni- 
torización y respuesta (la estación central que 
monitoriza HogarSeguro). Para los propósitos de este 
ejemplo, consideraremos solamente el actor propietario. 

La Figura 21.2.a muestra un diagrama de casos de 
uso de alto nivel para el propietario. En dicha figura 
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se identifican dos casos de uso y se representan con elip- 
ses. Cada caso de uso de alto nivel puede detallarse 
mediante diagramas de casos de uso de nivel inferior. 
Por ejemplo, la Figura 21.2.b representa un diagrama 
de casos de uso para la función interactúa. Se crea un 
conjunto completo de diagramas de casos de uso para 
todos los actores. Pero para una detallada discusión sobre 
los casos de uso usando UML es mejor consultar la 
bibliografía sobre el tema (p.e. [ERI97] o [ALH98]). 


21.4.2. Modelado de clases-responsabilidades- 
colaboraciones 


Una vez que se han desarrollado los escenarios de uso 
básicos para el sistema, es el momento de identificar las 
clases candidatas e indicar sus responsabilidadesy cola- 
boraciones. El modelado de c/ases-responsabilidades- 
colaboraciones (CRC) [WIR90] aportaun medio sencillo 
de identificar y organizar las clases que resulten relevantes 
al sistema o requisitos del producto. Ambler [AMB95] 
describe el modelado CRC de la siguiente manera: 
Un modelo CRC es realmente una colección de tarjetas 
índice estándar que representan clases. Las tarjetas están divi- 
didas en tres secciones. A lo largo de la cabecera de la tarjeta 
usted escribe el nombre de la clase. En el cuerpo se listan las 


responsabilidades de la clase a la izquierda y a la derecha los 
colaboradores. 


Referencia Web 


En www.univ-paris1.fr /CRINFO /dmrg/MEE97 /misop013 
puede consultor uno discusión detalloda de la técnico de las tarjetas CRC. 


En realidad, el modelo CRC puede hacer uso de tar- 
jetas índice virtuales o reales. El caso es desarrollar una 
representación organizada de las clases. Las responsa- 
bilidades son los atributos y operacionesrelevantes para 
la clase. Puesto de forma simple, una responsabilidad 
es «cualquier cosa que conoce O hace la clase» 
[AMB95]. Los colaboradores son aquellas clases nece- 
sarias para proveer a una clase con la informaciónnece- 
saria para completar una responsabilidad. En general, 
una colaboración implica una solicitud de información 
o una solicitud de alguna acción. 


Clases 


Las pautas básicas para identificar clases y objetos se 
presentaron en el Capítulo 20. Resumiendo, los objetos 
se manifiestan en una variedad de formas (Sección 
20.3.1): entidades externas, cosas, ocurrencias o suce- 
sos, roles, unidades organizativas, lugares, O estructu- 
ras. Una técnica para identificarlos en el contexto de un 
problema del software es realizar un análisis gramati- 
cal con la narrativa de procesamiento para el sistema. 
Todos los nombres se transforman en objetos potencia- 
les. Sin embargo, no todo objeto potencial podrá 
incluirse en el modelo. Un objeto potencial debe satis- 
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facer estas seis características para poder ser conside- 
rado como posible miembro del modelo: 


1. retener información: el objeto potencial será útil 
durante el análisis si la información sobre el mismo 


debe guardarse para que el sistema funcione 


. Servicios necesarios: el potencial objeto debe tener 
un conjunto de operaciones identificables que per- 
mitan cambiar los valores de sus atributos. 


. Múltiples atributos: durante el análisis de requisitos 
nos centramos más en la información más impor- 
tante. Un objeto con un solo atributo puede, en efecto, 
ser Útil durante el diseño, pero probablemente será 
un atributo de otro objeto durante el análisis de acti- 
vidades. 


. Atributos comunes: el conjunto de atributos definido 
para la clase debe ser aplicable a todas las ocurren- 
cias del objeto. 


HogarSeguro 


Plopietario 


(a) 


Introducir 
contraseña 


Solicitar 
el estado 
de la zona 


«usa» 


Solicitar 
Consultar 


sensor 


Propietario 


desactivar 
sistema 


(b) 


FIGURA 21.2. a) Diagrama de casos de uso de alto nivel. 
b) Diagrama de casos de uso detallado. 
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0 ¿Cómo determinar si merece la 
pena incluir un objeto potencial 
en una tarjeta índice CRC? 


. Operaciones comunes: el objeto potencial debe defi- 
nir un conjunto de operaciones aplicables, al igual 
que antes, a todos los objetos de la clase. 

. Requisitos esenciales: las entidades externas que apa- 
recen en el espacio del problema y producen infor- 
mación esencial para la operación de una solución 
para el sistema casi siempre se definen como obje- 
tos en el modelo de requisitos. 


Una clase potencial debe satisfacer las seis caracte- 
rísticas de selección anteriores si va a ser incluida en el 
modelo CRC. 

Firesmith [FIR93] extiende las características de cla- 
sificación sugiriendo, además de las existentes, las 
siguientes: 

Clases dispositivo. Modelan entidades externas tales 
como sensores, motores y teclados. 

Clases propiedad. Representan alguna propiedad 
importante del entorno del problema (por ejemplo: esta- 
blecimiento de créditos dentro del contexto de una apli- 
cación de préstamos hipotecarios). 

Clases interacción. Modelan interacciones que ocu- 
rren entre otros objetos (por ejemplo: una adquisición o 
una licencia). 


¿Hay alguna manera de clasificar 
las clases? ¿Qué características 
nos ayudan a hacerlo? 


Adicionalmente, los objetos y clases pueden clarifi- 
carse por un conjunto de características: 


Tangibilidad. ¿Representa la clase algo tangible o 
palpable (por ejemplo, un teclado o sensor), o repre- 
senta información más abstracta (por ejemplo: una salida 
prevista)? 

Inclusividad. ¿Es la clase atómica (es decir, no 
incluye otras clases) o es agregada (incluye al menos 
un objeto anidado)? 

Secuencia. ¿Es la clase concurrente (es decir posee 
su propio hilo de control) o secuencial (es controlada 
por recursos externos)? 

Persistencia. La clase es temporal (se crea durante 
h ejecución del programa y es eliminada una vez que 
éste termina), opermanente (es almacenada en una base 
de datos)? 

Integridad. ¿Es la clase corrompible (es decir, no pro- 
tege sus recursos de influencias externas) O es segura (la 
clase refuerza los controles de accesos a-sus recursos)? 


Usando estas categorías de clases, pueden ampliar- 
se las «tarjetas índice» creadas como parte del modelo 
CRC para incluir el tipo de la clase y sus característi- 
cas (Fig. 21.3). 
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Responsabilidades 


Las pautas básicas para identificar responsabilidades 
(atributos y operaciones) también fueron presentadas 
en el Capítulo 20. Para resumir, los atributos represen- 
tan características estables de una clase, esto es, infor- 
mación sobre la clase que debe retenerse para llevar a 
cabo los objetivos del software especificados por el 
cliente. Los atributos pueden a menudo extraerse del 
planteamiento de alcance o discernirse a partir de la 
comprensión de la naturaleza de la clase. Las opera- 
ciones pueden extraerse desarrollandoun análisis gra- 
matical sobre la narrativa de procesamiento del sistema. 
Los verbos se transforman en candidatos a operaciones. 
Cada operación elegida para una clase exhibe un com- 
portamiento de la clase. 


%] 
Ss 


CLAVE 


las responsabilidades de una clase incluyen tanto a los 
atributos como a las operaciones. 


Wirfs-Brock y sus colegas [WIR90] sugieren cinco 
pautas para especificarresponsabilidades para las clases: 


l. La inteligencia del sistema debe distribuirse de 
manera igualitaria. Toda aplicación encierra un cierto 
grado de inteligencia, por ejemplo, lo que sabe el sis- 
tema y lo que puede hacer. Esta inteligencia puede 
distribuirse ente las clases de varias maneras. Las 
clases «tontas» (aquellas con pocas responsabilida- 
des) pueden modelarse de manera que actúen como 
sirvientes de unas pocas clases «listas» (aquellas con 
muchas responsabilidades). Aunque este enfoque 
hace que el flujo de control dentro de un sistema sea 
claro, posee algunas desventajas: (1) Concentra toda 
la inteligenciaen pocas clases, haciendo los cambios 
más difíciles; (2) Tiende a necesitar más clases y por 
lo tanto el esfuerzo de desarrollo aumenta. 


Por esta razón, la inteligencia del sistema debe 
distribuirse de manera igualitariaentre las clases de 
una aplicación. Como cada objeto conoce y actúa 
sobre algunos pocos elementos (generalmente bien 
definidos y claros), la cohesión del sistema se ve 
incrementada. Adicionalmente, los efectos colatera- 
les provocados por cambios tienden a amortiguarse 
debido a que la inteligencia del sistema se ha des- 
compuesto entre muchos objetos. 


Ronseso 


Si unaclase tiene unalisto excesivamente larga de 
responsabilidades, tal vezdebería considerarsesu división 
en varías clases menores. 


¿Cómo asignar responsabilidades 
a una clase? 
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Para determinar si la inteligencia del sistema está 
distribuida equitativamente, las responsabilidades 
definidas en cada tarjeta índice del modelo CRC 
deben ser evaluadas para determinar si cada clase 
posee una lista de responsabilidades extraordina- 
riamente grande. Esto indica una concentración de 
inteligencia. Además, las responsabilidades de cada 
clase deben mostrar el mismo nivel de abstracción. 
Por ejemplo, entre la lista de operaciones de una 
clase agregada llamada Comprobación de cuenta 
existen dos responsabilidades: saldo-de-la-cuenta 
y verificar-talones-cobrados. La primera operación 
(responsabilidad) implica un complejo procedi- 
miento matemático y lógico. La segunda es una sim- 
ple actividad para empleados. Debido a que estas 
dos actividades no están al mismo nivel de abs- 
tracción, verificar-talones-cobrados debe situarse 
dentro de las responsabilidades de la clase Com- 
probación de entradas, la cual está contenida en 
la clase agregada Comprobación de cuenta. 


po del clase: (dispositivo, propiedad, ro, evento.) | 


FIGURA 21.3. Un modelo CRC de tarjeta índice. 


2. Cada responsabilidad debe establecerse lo más gene- 
ral posible. Esta directriz implica que las responsa- 
bilidades generales (tanto los atributos como las 
operaciones) deben residir en la parte alta de lajerar- 
quía de clases (puesto que son genéricas, se aplica- 
rán a todas las subclases). Adicionalmente, debe 
usarse el polimorfismo (Capítulo 20) para definir las 
Operaciones que generalmente se aplica a la super- 
clase, pero que se implementan de manera diferente 
en cada una de las subclases. 


3. La informacióny el comportamientoasociado a ella, 
debe encontrarse dentro de la misma clase. Esto 
implementa el principio VO de encapsulamiento 
(Capítulo 20). Los datos y procesos que manipulan 
estos datos deben empaquetarse como una unidad 
cohesionada. 


. La información sobre un elemento debe estar loca- 
lizada dentro de una clase, no distribuida a través 
de varias clases. Una clase simple debe asumir la 
responsabilidad de almacenamiento y manipulación 
de un tipo específico de información. Esta respon- 
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sabilidad no debe compartirse, de manera general, 
entre varias clases. Si la información está distri- 
buida, el software se torna más difícil de mantener 
y probar. 


5. Compartir responsabilidades entre clases relacio- 
nadas cuando sea apropiado. Existen muchos casos 
en los cuales una gran variedad de objetos exhibe el 
mismo comportamiento al mismo tiempo. Como un 
ejemplo, considere un videojuego que debe mostrar 
los siguientes objetos: jugador, cuerpo-del-juga- 
dor, brazos-del-jugador,cabeza-del-jugador. Cada 
uno de estos atributos tiene sus propios atributos (p.*.: 
posición, orientación, color, velocidad), y todos 
deben actualizarse y visualizarse al mover el usua- 
rio eljoystick. Las responsabilidades actualizar y 
visualizar deben, por lo tanto, compartirse por los 
objetos señalados. El jugador sabe cuándo algo ha 
cambiado y se requiere actualizar; colabora con los 
otros objetos para alcanzar una nueva posición u 
orientación, pero cada objeto controla su propia 
visualización. 


Colaboradores 


Las clases cumplen con sus responsabilidades de una 
de las dos siguientes maneras: (1) una clase puede 
usar sus propias operaciones para manipular sus pro- 
pios atributos, cumpliendo por lo tanto con una res- 
ponsabilidad particular, o (2) puede colaborar con 
otras clases. 


Wirfs-Brock[WIR90] y sus colegas definen las cola- 
boraciones de la siguiente forma: 


Las colaboraciones representan solicitudes de un cliente a 
un servidor en el cumplimiento de una responsabilidad del 
cliente. Una colaboraciónes la realización de un contrato entre 
el cliente y el servidor... Decimos que un objeto colabora con 
otro, si para ejecutar una responsabilidad necesita enviar cual- 
quier mensaje al otro objeto. Una colaboración simplefluye en 
una dirección, representando una solicitud del cliente al servi- 
dor. Desde el punto de vista del cliente, cada una de sus cola- 
boraciones está asociada con una responsabilidad particular 
implementada por el servidor. 


Un objeto servidor colabora con un objetos cliente 
en un esfuerzo por llevar o cabo una determinada 
responsabilidad. la colaboración implicael paso de mensajes. 


Las colaboraciones identifican relaciones entre cla- 
ses. Cuando todo un conjunto de clases colabora para 
satisfacer algún requisito, es posible organizarlas en un 
subsistema (un elemento del diseño). 

Las colaboraciones se identifican determinando si 
una clase puede satisfacer cada responsabilidad. Si no 
puede, entonces necesita interactuar con otra clase. De 
aquí surge'lo que hemos llamado una colaboración. 


www.elsolucionario.net 


Como un ejemplo, considere la aplicación Hogar- 
Seguro”. Como una parte del procedimiento de activa- 
ción (vea el caso de uso para activación en la sección 
11.2,4), el objeto panel de control debe determinar si 
existen sensores abiertos. Se define una responsabili- 
dad llamada determinar-estado-del-sensor.Si hay sen- 
sores abiertos, el panel de control debe poner el atributo 
estado al valor «no preparado». La información del sen- 
sor puede obtenerse del objeto sensor. Por lo tanto, la 
responsabilidad determinar-estado-del-sensor puede 
ejecutarse solamente si el panel de control trabaja en 
colaboración con el sensor. 

Para ayudar en la identificación de colaboradores, el 
analista puede examinar tres relaciones genéricas dife- 
rentes entre clases [WIR90]: (1) la relación es-parte-de, 
(2) la relación tiene-conocimiento-sobre, y (3) la rela- 
ción depende-de. A través de la creación de un diagra- 
ma de relación entre clases (Sección 2 1.4.4), el analista 
desarrolla las conexiones necesarias para identificarestas 
relaciones. Cada una de las tres relaciones genéricas se 
considera brevemente en los párrafos siguientes. 

Todas las clases que forman parte de una clase agre- 
gada están conectadas a ésta a través de una relación es- 
parte-de. Considere las clases definidas para el juego de 
vídeo mencionado anteriormente, la clase cuerpo-del- 
jugador es-parte-de, al igual que cuerpo-del-jugador, 
brazos-del-jugador y cabeza-del-jugador. 

Cuando una clase debe obtener información sobre 
otra, se establece la relación tiene-conocimiento-sobre. 
La responsabilidad determinar-estado-del-sensores un 
ejemplo de la relación tiene-conocimiento-sobre. La 
relación depende-de implica que dos clases poseen una 
dependencia no realizable a través de tiene-conoci- 
miento-sobre o es-parte-de. Por ejemplo, la cabeza-del- 
jugador debe estar siempre conectada al cuerpo- 
del-jugador (a menos que el videojuego en particular 
sea muy violento), aunque cada objeto puede existir sin 
conocimiento directo sobre el otro. Un atributo del obje- 
to cabeza-del-jugador llamado posición-central se 
obtiene de la posición-central del objeto cuerpo-del- 
jugador. Esta información se obtiene a través de un ter- 
cer objeto, jugador, el cual la obtiene del 
cuerpo-del-jugador. Por lo tanto, la cabeza-del-juga- 
dor depende-de cuerpo-del-jugador. 

En todos los casos, el nombre de la clase colaborado- 
ra se registra en la tarjeta índice del modelo CRC al lado 
de la responsabilidad que ha generado dicha colabora- 
ción. Por lo tanto, la tarjeta índice contiene una lista de 
responsabilidadesy de colaboraciones correspondientes 
que posibilitan se realicen las responsabilidades su rea- 
lización (Fig. 21.3). 

Cuando se ha desarrolladoun modelo CRC por com- 
pleto, los representantes del cliente y de las organiza- 
ciones de ingeniería del software pueden recorrer el 
modelo haciendo uso del siguiente enfoque. 


$ Vea una explicación de las clases de Hogarseguroen la Sección 


20.3. 
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NMarilULN, Ll 
$ ¿Qué enfoque efectivo 

existe para revisar un 
modelo CRC? 


1. A todos los participantes de la revisión (del modelo 
CRC) se les da un subconjunto de las tarjetas índice 
del modelo CRC. Las tarjetas que colaboran deben 
estar separadas (esto es, ningún revisor debe poseer 
dos tarjetas que colaboren). 


. Todos los escenarios (y sus correspondientes diagra- 
mas de casos de uso) deben organizarse en categorías. 


El director de la revisión lee el caso de uso con aten- 
ción. Cuando el director llega a un objeto identifi- 
cado, se traspasa la señal a la persona que posee la 
clase tarjeta índice correspondiente. Por ejemplo, el 
caso de uso mencionado en la Sección 20.4.1 con- 
tiene la siguiente narración: 

El propietario de la casa observa el panel de control de 
Hogarseguropara determinarsi el sistemaestá listo para entra- 
da de datos. Si el sistema no está listo, el propietario debe cerrar, 
físicamente, las ventanas y puertas para que aparezca el indi- 
cador de «listo», [Un indicador no listo implica que un sensor 
está abierto, esto es que una puerta o ventana está abierta.] 


Cuando el director de la revisión llega al «panel de 
control» en la narrativa del caso de uso, se pasa la 
señal a la persona que posee la tarjeta panel de con- 
trol. La frase «implica que un sensor está abierto» 
requiere que la tarjeta índice contenga una respon- 
sabilidad que validará esta implicación (la respon- 
sabilidad determinar-estado-del-sensor realiza esta 
acción). Al lado de la responsabilidad en la tarjeta 
índice está el colaborador sensor. La señal se pasa 
entonces al objeto sensor. 

Cuando se pasa la señal, se le pide al que posee la 
tarjeta de la clase que describa las responsabilidades 
mencionadas en la tarjeta. El grupo determina si una 
(o más) de las responsabilidades satisface el requi- 
sito del caso de uso. 


Si las responsabilidades y colaboraciones mencio- 
nadas en las tarjetas índice no pueden acomodarse 
al caso de uso, se hacen modificaciones a las tarje- 
tas. Esto puede incluir la definición de nuevas cla- 
ses (y sus correspondientes tarjetas índice CRC) o la 
especificación de responsabilidades y colaboracio- 
nes nuevas o revisadas en tarjetas existentes. 


Este modus operandi continúa hasta terminar el caso 
de uso. Cuando terminan todos los casos de uso, conti- 
núa el análisis OO. 


21.4.3. Definición de estructuras y jerarquías 


Una vez que se han identificado las clases y objetos usan- 
do el modelo CRC, el analista comienza a centrarse en 
la estructura del modelo de clases y las jerarquías resul- 
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tantes que surgen al emerger clases y subclases. Usan- 
do la notación UML podemos crear gran variedad de 
diagramas. Debe crearse una estructura de generaliza- 
ción-especialización para las clases identificadas. 

Para ilustrarlo considere el objeto sensor definido 
para HogarSeguro y mostrado en la Figura 21.4. Aquí, 
la generalización, sensor, se refina en un conjunto de 
especializaciones: sensor de entrada, sensor de humo 
y sensor de movimiento. Los atributos y operaciones 
identificados en el sensor son heredados por las espe- 
cializaciones de la clase. Hemos creado una jerarquía 
de clases simple. 

En otros casos, un objeto representado según el 
modelo inicial puede estar compuesto realmente de un 
número de partes las cuales pueden definirse a su vez 
como objetos. Estos objetos agregados pueden repre- 
sentarse como una estructura componente-agregado 
[ERI97] y se definen usando la notación representada 
en la Figura 21.5. El rombo implica una relación de 
ensamblaje. Debe notarse que las líneas de conexión 
pueden aumentarse con símbolos adicionales (no mos- 
trados) para representar cardinalidad, que se adaptan de 
la notación del modelo entidad-relación descrito en el 
Capítulo 12. 

Las representaciones estructurales proveen al ana- 
lista de los medios para particionar el modelo CRC y 
para representar esta partición gráficamente. La expan- 
sión de cada clase aporta los detalles necesarios para 
revisión y para el subsiguiente diseño. 


21.44. Definición de subsistemas 


Un modelo de análisis para una aplicación compleja pue- 
de tener cientos de clases y docenas de estructuras. Por 
esta razón, es necesario definir una representación con- 
cisa que sea un resumen de los modelos CRC y estruc- 
tural descritos anteriormente. 


e, 
o CLA VE 


Un suossema (paquetede UML) incluye una jerarquía 
de clases más detaleda. 


Los subconjuntos de clases que colaboran entre sí 
para llevar a cabo un conjunto de responsabilidades 
cohesionadas, se les llama normalmente subsistemas 
opaquetes (en terminología UML). Los subsistemas 
O paquetes son abstracciones que aportan una refe- 
rencia o puntero a los detalles en el modelo de análi- 
sis. Si se observa desde el exterior, un subsistema 
puede tratarse como una caja negra que contiene un 
conjunto de responsabilidades y que posee sus pro- 
pios colaboradores (externos). Un subsistema imple- 
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menta uno o más contratos [WIR90] con sus colabo- 
radores externos. Un contrato es una lista específica 
de solicitudes que los colaboradores pueden hacer a 
un subsistema". 


Sensor 


Sensor 
de movimiento 


Atributos | 


Sensor 


de entrada 


FIGURA 21.4.a Diagrama de clases que ilustra la relación 
de generalización-especialización. 


Panel 
de conirol 


Teclado | Pantalla | Luz | 


FIGURA 21.5.a Diagrama de clases que ilustra la relación 
de agregación. 


Los subsistemas pueden representarse dentro del 
contexto del modelo CRC creando una tarjeta índice 
del subsistema. La tarjeta índice del subsistema indi- 
ca el nombre del subsistema, los contratos que debe 
cumplir y las clases u otros subsistemas que soportan 
el contrato. 

Los paquetes son idénticos a los subsistemas en 
intención y contenido, pero se representan gráfica- 
mente en UML. Por ejemplo, suponga que el panel de 
control de HogarSeguro es considerablemente más 
complejo que el representado por la Figura 21.5, con- 
teniendo múltiples monitores, una sofisticada distri- 
bución de teclas y otras características. Éste pudiera 
modelarse como una estructura todo-partes mostrada 
en la Figura 21.6. Si el modelo de requisitos contu- 
viera docenas de estas estructuras (HogarSeguro no 
las tendrá), sería difícil absorber la representación 
completa de una vez. Definiendo una referencia de 


7 Recuerde que las clases interactúan usando una filosofía cliente/ser- 
vidor. En este caso el subsistema es el servidor y los colaboradores 
externos los clientes. 
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temas, como se muestra en la figura, pudiera referen- 
ciarse toda la estructura a través de un simple icono 
(la carpeta de ficheros). Las referencias de paquetes 
se crean generalmente para cualquier estructura que 
posea múltiples objetos. 

Al nivel más abstracto, el modelo de AOO conten- 
drá solamente referencias de paquetes tales como las 
que se ilustran al inicio de la Figura 21.7. Cada una de 
las referencias se expandirá a una estructura. Se ilus- 
tran las estructuras para los objetos panel de control y 
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sensor (Figs. 21.5 y 21.6); para el sistema, suceso sen- 
sor y alarma audible se crearán también estructuras si 
estos objetos necesitan objetos ensamblados. 

Las flechas discontinuas mostradas en la parte supe- 
rior de la Figura 21.7 representan relaciones de depen- 
dencia entre los paquetes que se muestran. Sensor 
depende del estado del paquete suceso sensor. Las fle- 
chas continuas representan composición. En el ejem- 
plo, el paquete sistema está compuesto por los paquetes 
panel de control, sensor y alarma audible. 


El enfoque del modelado CRC usada en secciones ante- 
riores ha establecido los primeros elementos de las rela- 
ciones de clases y objetos. El primer paso en el 
establecimientode las relaciones es comprender las res- 
ponsabilidades de cada clase. La tarjeta índice del mode- 
lo CRC contiene una lista de responsabilidades. El 
siguiente paso es definir aquellas clases colaboradoras 
que ayudan en la realización de cada responsabilidad. 
Esto establece la «conexión» entre las clases. 

Entre dos clases cualesquiera que estén conectadas 
existe una relación*. Debido a esto los colaboradores 
siempre están relacionados de alguna manera. El tipo de 
relación más común es la binaria (existe una relación 
entre dos clases). Cuando se analiza dentro del contexto 
de un sistema OO, una relación binaria posee una direc- 
ción específica” que se define a partir de qué clase desem- 
peña el papel del cliente y cuál actúa como servidor. 

Rumbaugh y sus colegas [RUM91] sugieren que las 
relaciones pueden derivarse a partir del examen de los 
verbos O frases verbales en el establecimiento del alcan- 
ce o casos de uso para el sistema. Usando un análisis 
gramatical, el analista aísla verbos que indican locali- 
zaciones físicas o emplazamientos (cerca de, parte de, 
contenido en ), comunicaciones (transmite a, obtenido 
de), propiedad (incorporadopor, se compone de) y cum- 
plimiento de una condición (dirige, coordina, contro- 
la). Estos aportan una indicación de la relación. 

La notación del lenguaje unificado de modelado para 
el modelo objeto-relación utiliza una simbología adap- 
tada de las técnicas del modelo entidad-relaciónexami- 
nadas en el Capítulo 12. En esencia, los objetos se 
conectan con otros objetos utilizando relaciones con nom- 
bres. Se especifica la cardinalidad de la conexión (ver 
capítulo 12) y se establece toda una red de relaciones. 


> ¿Cómo se obtiene un modelo 
E" objeto-relación? 


$ Otros términos para relación son asociación [RUM91] y conexión 
[COA91]. 


Panel de Es | 


Referencia 


Panel de control 


subsistema: 
(paquete, 


Área 
de pantalla 


Luz 


FIGURA 21.6. Referencia a paquete (subsistema). 


El modelo objeto-relación (como el modelo entidad- 
relación) puede obtenerse en tres pasos o etapas: 


1 Usando las tarjetas índice CRC, puede dibujarse una 
red de objetos colaboradores. La Figura 21.8 repre- 
senta las conexiones de clase para los objetos de 
HogarSeguro. Primero se dibujan los objetos conec- 
tados por líneas sin etiquetas (no se muestran en la 
figura) que indican la existencia de alguna relación 
entre los objetos conectados. Una alternativa es mos- 
trar los nombres de los roles de cada clase en la rela- 
ción en lugar del nombre de la relación. Esto se 
describe en el Capítulo 22. 


2. Revisando el modelo CRC de tarjetas índices, se eva- 
lúan responsabilidadesy colaboradores y cada línea 
de conexión sin etiquetar recibe un nombre. Para evi- 
tar ambigiiedades, una punta de flecha indica la 
«dirección» de la relación (Fig. 21.8). 


3. Una vez que se han establecido y nombrado las rela- 
ciones, se evalúa cada extremopara determinar la car- 


? Es importante notar que esta es una salida de la naturaleza bidi- 
reccional de las relaciones usadas en el modelado de datos (Capí- 
tulo 12). 
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dinalidad (Fig. 21.8). Existen cuatro opciones: 0a 1, 
la 1,0 a muchos, Ó 1 a muchos. Por ejemplo, el sis- 
tema HogarSeguro contiene un único panel de control 
(la cardinalidad 1 lo indica). Al menos un sensor debe 
estar presente para que el panel de control lo active. 
Sin embargo, varios sensores pueden estar presentes 
(la relación 1.. loindica). Un sensor puede reconocer 
lo más sucesosde sensor (p.e.: se detecta humo u ocu- 
rre una caída, pues el símbolo 1..* lo indica). 


Panel de control 
| 
Evento de sor] 
: | 


HogarSeguro 


—— 


Alarma audible 


Teclas 


de función] [Pantalla LCD [Mensajes | 
+ A | (SS 


Un panel de control controla uno o más sensores 
y cada sensor es controlado por un panel de control 


Controla . 


Panel 
de contro! 


Un sistema está formado por cero Ó más alarmas audibles ¡ 


y una alarma audible está asociada con un único sistema j 


FIGURA 21.8. Relaciones entre objetos. 


Los pasos anteriormente mostrados continúan hasta 
que se produzca un modelo objeto-relación completo. 

En el desarrollo de un modelo objeto-relación.el ana- 
lista añade aún alguna otra dimensión al modelo de aná- 
lisis general. No solamente se identifican las relaciones 
entre objetos, sino que se definen todas las vías impor- 
tantes de mensajes (Capítulo 20). En nuestra descrip- 
ción de la Figura 21.7, hicimos referencia a las flechas 
que conectan símbolos de paquetes. También son vías 
de mensajes. Cada flecha implica el intercambio de men- 
sajes entre subsistemas en el modelo. 


El modelo CRC y el de objeto-relaciónrepresentan ele- 
mentos estáticos del modelo de análisis OO. Ahora es el 
momento para hacer una transición al comportamiento 
dinámico del sistema o producto OO. Para ejecutar este 
paso debemos representar el comportamiento del siste- 
ma como una función de sucesos específicos y tiempo. 


¿Cuáles son los posos 
o seguir poro construir un 
modelo objetos-tomportomiento? 


El modelo objeto-comportamientoindica cómo res- 
ponderá un sistema OO a sucesos externos o estímulos. 
Para crear el modelo, el analista debe ejecutar los 
siguientes pasos: 

1. Evaluar todos los casos de uso (Sección 21.4.1) para 
comprender totalmente la secuencia de interacción 
dentro del sistema. 

. Identificar sucesos que dirigen la secuencia de inter- 
acción y comprendercómo estos sucesos se relacionan 
con objetos específicos. 

. Crear una traza de sucesos [RUM9]] para cada caso 
de uso. 

. Construir un diagrama de transición de estados para 
el sistema. 
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5. Revisar el modelo objeto-comportamiento para veri- 
ficar exactitud y consistencia. 


Cada uno de estos pasos se discute en las secciones 
siguientes. 


21.6.1. Identificaciónde sucesos con casos de uso 


Como vimos en la Sección 21.4.1, el caso de uso 
representa una secuencia de actividades que incluyen 
a actores y al sistema. En general, un suceso ocurre 
cada vez que un sistema OO y un actor (recuerde que 
un actor puede ser una persona, un dispositivo o inclu- 
so un sistema externo) intercambian información. 
Recordando la explicación dada en el Capítulo 12, es 
importante recordar que un suceso es Booleano. Esto 
es, un suceso no es la información que se intercam- 
bia, es el hecho de que la información ha sido inter- 
cambiada. 

Un caso de uso se examina por puntos de intercam- 
bio de información. Para ilustrarlo, reconsidere el caso 
de uso descrito en la Sección 11.2.4: 

1. El propietario observa el panel de control de HogarSeguro 
(Figura 11.2) para determinar si el sistema está listo para 
recibir datos. Si el sistema no está listo, el propietario debe 


cerrar físicamente ventanas y puertas de tal manera que el 
indicador de disponibilidad esté presente. [Un indicador de 
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no preparado implica que el sensor está abierto, por ejem- 
plo, que una puerta O ventana está abierta.] 


2. El propietario usa el teclado para teclear una contraseña de 
cuatro dígitos. La contraseña se compara con la contraseña 
válida almacenada en el sistema. Si la contraseña es inco- 
rrecta, el panel de control avisará una vez y se restaurará 
por sí mismo para recibir datos adicionales. Si la contrase- 
ña es correcta, el panel de control espera por las acciones 
siguientes. 


3. El propietario selecciona y teclea permanecer o continuar 
para activar el sistema. Permanecer activa solamente los sen- 


sores del perímetro (los sensores internos detectores de movi- 
miento están desactivados). Continuar activa todos los 
sensores. 


4. Cuando ocurre la activación, el propietario puede observar 
una luz roja de alarma. 


Las partes de texto subrayadas anteriormenteindican 
sucesos. Deberá identificarseun actor para cada suceso: 
la información que se intercambia debe anotarse. y debe- 
rán indicarse otras condiciones o restricciones. 

Como ejemplo de un suceso típico, considere la fra- 
se subrayada del caso de uso propietario usa el teclado 
para teclear una contraseña de cuatro dígitos. En el con- 
texto del modelo de análisis OO el actor propietario 
transmite un suceso al objeto panel de control. 

El suceso puede llamarse contraseña introducida. 
La información transferida son los cuatro dígitos que 
forman la contraseña, pero ésta no es una parte esencial 
del modelo de comportamiento. Es importantenotar que 
algunos sucesos tienen un impacto explícito en el flujo 
de control del caso de uso, mientras que otros no impac- 
tan directamente en este flujo de control. Por ejemplo. 
el suceso contraseña introducida no cambia explícita- 
mente el flujo de control del caso de uso, pero los resul- 
tados del suceso comparar contraseña (derivada de la 
interacción contraseña se compara con la contraseña 
válida almacenada en el sistema) tendrá un impacto 
explícito en la información y flujo de control del soft- 
ware HogarSeguro. 

Una vez que todos los sucesos han sido identifica- 
dos, se asocian a los objetos incluidos. Los actores (enti- 
dades externas) y objetos pueden responsabilizarse de 
la generación de sucesos (p.e.: propietario genera el 
suceso contraseña introducida) o reconociendo suce- 
sos que han ocurrido en otra parte (p.e.: el panel de con- 
trol reconoce el resultado binario del suceso comparar 
contraseña). 


21.6.2. Representaciones de estados 


En el contexto de sistemas OO deben considerarse dos 
caracterizaciones de estados: (1) el estado de cada obje- 
to cuando el sistema ejecuta su función, y (2) el estado 
del sistema observado desde el exterior cuando éste eje- 
cuta su función. 

El estado de un objeto adquiere en ambos casos carac- 
terísticas pasivas y activas [CHAR93]. Un estado pasi- 
vo es simplementeel estado actual de todos los atributos 
de un objeto. Por ejemplo, el estado pasivo del objeto 
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agregadojugador (en la aplicación del videojuego exa- 
minado anteriormente) incluirá posición y orientación 
actual del jugador (atributos del objeto) así como otras 
características de jugador que son relevantes al juego 
(p.e.: un atributo que indique permanecen deseos mági- 
cos). El estado activo de un objeto indica el estado actual 
cuando éste entra en una transformación continua o pro- 
ceso. El objeto jugador poseerá los siguientes estados 
activos: en movimiento, en descanso, lesionado, en recu- 
peración, atrapado, perdido entre otros. Para forzar la 
transición de un objeto de un estado activo a otro debe 
ocurrir un suceso (a veces, llamado disparador). Un com- 
ponente de un modelo objeto-comportamiento es una 
representación simple de los estados activos de cada obje- 
to y los sucesos (disparadores)que producen los cambios 
entre estos estados activos. La Figura 21.9 ilustra una 
representación simple de los estados activos para el obje- 
to panel de control en el sistema HogarSeguro. 


UN 


Cuando se empiezon o identificar estados, lo atención 
se centro en los modos de Comportamientoobservables 
desde el exterior. Más tarde, se pueden refinar estos 
estados en comportamientos no evidentes cuando 

se observo el sistema desde el exterior. 


Cada flecha en la Figura 21.9 representa una transi- 
ción de un estado activo del objeto a otro. Las etique- 
tas mostradas en cada flecha representan los sucesos 
que disparan la transición. Aunque el modelo de esta- 
do activo aporta una visión interna muy útil de la «his- 
toria de vida» de un objeto, es posible especificar 
información adicional para aportar más profundidad en 
la comprensión del comportamiento de un objeto. Adi- 
cionalmente a especificarel suceso que provoca la ocu- 
rrencia de la transición, el análisis puede también 
especificar una guarda y una acción [CHAR93]. Una 
guarda es una condición Booleana, que debe satisfa- 
cerse para posibilitar la ocurrencia de una transición. 
Por ejemplo, la condición de guarda para la transición 
desde el estado «en descanso» al de «comparando» en 
la Figura 20.9 puede determinarse a través del examen 
del caso de uso: 


if (entrada de contraseña = 4 dígitos) 
then ejecutar transición al estado comparando; 


En general, la guarda de una transición depende 
usualmente del valor de uno O más atributos de un obje- 
to. En otras palabras, la condición de guarda depende 
del estado pasivo del objeto. 

Una acción ocurre concurrentementecon la transición 
o como una consecuencia de ella y generalmente implica 
una O más operaciones (responsabilidades) del objeto. Por 
ejemplo, la acción conectada con el suceso contraseña 
introducida (Fig. 21.9) es una operación que accede a un 
objeto contraseña y realiza una comparación dígito a dígi- 
to para validar la contraseña introducida. 
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Volver 
a entrar 


Comparar contraseña 
[contraseña incorrecta] 


Comparar contraseña 
Se introduce Com d [contraseña incorrecta] 
la contraseña parando 
Comparar contraseña 


[contraseña correcta] 


Activación 


Seleccionando 
correcta 


FIGURA 21.9. Representación de la transición de estados. 


El segundo tipo de representación de comportamiento 
para el AOO considera una representación de estados 
para el producto general o sistema. Esta representación 
abarca un modelo simple de traza de sucesos [RUM91] 
que indica cómo los sucesos causan las transiciones de 
objeto a objeto y un diagrama de transición de estados 
que ilustra el comportamiento de cada objeto durante el 
procesamiento. 

Una vez que han sido identificados los sucesos para 
un caso de uso, el analista crea una representación 
acerca de cómo los sucesos provocan el flujo desde 
un objeto a otro. Esta representación, llamada traza 
de sucesos o de sucesos, es una versión abreviada del 
caso de uso que representa objetos clave y los suce- 
sos que provocan el comportamiento de pasar de obje- 
to a objeto. 


CLAVE 


Una transición de un estado a otro requiere un suceso que 
la produzca. los sucesos son booleanos por naturaleza ya 
menudo ocurren cuando un objeto se comunica con otro. 


La Figura 21.10 ilustra una traza parcial de sucesos para 
el sistema HogarSeguro. Cada una de las flechas repre- 
senta un suceso (derivado de un caso de uso) e indica cómo 
el suceso sintoniza su comportamientoentre los objetos 
de HogarSeguro. El primer suceso, sistema listo, se deri- 
va del entorno exterior y sintoniza el comportamiento al 
propietario.El propietariotecleauna contraseña.El suce- 
so inicia aviso y aviso sonoro indican cómo se canaliza el 
comportamiento si la contraseñano es válida. Una con- 
traseña válida provoca un retomo al propietario. Los suce- 
sosrestantes y sus trazas siguen el comportamiento como 
cuando se activa O desactiva el sistema. 

UML utiliza diagramas de estado, de secuencia, de 
colaboración y de actividades para representar el com- 
portamiento dinámico de los objetos y las clases iden- 
tificadas como parte del modelo del análisis. 


Panel de control 


Sistema_ Introducir 
Iniciar sonido 


listo =P contraseña 
] Y 
, 1 
E 
IEnagondeivación] Sonido 
Seleccionar , 
| permanecer/salir > Activar/desactivar > 


sensores 


; a Sensores 
' Y activados/desactivados 
! Petición de luz roja ' 
E Luz roja encendida , 
: Preparado para F 


£ > 
1 nueva acción 


FIGURA 21.10. Traza de sucesos parcial para el sistema 
Hogarseguro. 


Los métodos de ADO permiten a un ingeniero del soft- 
ware modelar un problema representando las caracte- 
rísticas tanto dinámicas como estáticas de las clases y 
sus relacionescomo componentesprincipales del mode- 
lado. Como los métodos precedentes, el lenguaje unifi- 
cado de modelado UML construye un modelo de análisis 
con las siguientes características: (1) representación de 
las clases y jerarquías de clases, (2) creación de mode- 
los objeto-relación, y (3 )obtención de modelos objeto- 
comportamiento. 

El análisis de sistemas orientados a objetos se reali- 
za a muchos niveles diferentes de abstracción. En los 
niveles de empresa O de negocio las técnicas asociadas 
con el análisis se pueden conjugar con el enfoque de 
ingeniería del proceso de negocio. A estas técnicas a 
menudo se las llama de análisis del dominio. En el nivel 
de implementación el modelo de objetos se centra en 
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los requisitos especificados por el cliente tal y como 
éstos afectan a la aplicación a construir. 

El proceso de AOO comienza con la definición de 
casos de uso (escenarios que describen cómo se va a 
utilizar el sistema). La técnica de modelado de clases- 
responsabilidades-colaboraciones (CRC) se aplica para 
documentar las clases y sus atributos y operaciones. 
También proporciona una vista inicial de las colabora- 
ciones que ocurren entre los objetos. El siguiente paso 
enel AOO es la clasificación de objetos y la creación 
de una jerarquía de clases. Los sistemas (paquetes) se 
pueden utilizar para encapsular objetos relacionados. 
El modelo objeto-relación proporciona información 
sobre las conexiones entre las clases, mientras que el 
modelo objeto-comportamiento representa el compor- 
tamiento de los objetos individualmente y el global de 
todo el sistema. 
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21.1. Hágase con uno o más libros sobre UML y compárelo 
con el análisis estructurado(Capítulo 12) utilizando las dimen- 
siones de modelado propuestas por Fichman y Kemerer 
[FIC92] en la Sección 2 1.1.1. 


21.2. Desarrolle una clase-presentación sobre un diagrama 
estático o dinámico de UML. Presente el diagrama en el con- 
texto de un ejemplo sencillo, pero intente mostrar el suficien- 
te nivel de detalle como para demostrar los aspectos más 
importantes del tipo de diagrama elegido. 


21.3. Conduzca un análisis del dominio para una de las siguien- 
tes áreas: 


a) Un sistema para almacenar los expedientes de los alumnos 
de una universidad. 


b) Una aplicación de comercio electrónico (p.e. ropa, libros, 
equipos electrónicos, etc.) 


c) Un servicio al cliente para un banco. 
d) El desarrollo de un videojuego. 


e) Un área de aplicación propuesta por su instructor. 


21.4, Describa con sus propias palabras la diferencia entre las 
vistas estática y dinámica de un sistema. 
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21.5. Escriba un caso de uso para el sistema HogarSeguro. Los 
casos de uso deben tratar el escenario requerido para establecer 
una zona de seguridad. Una zona de seguridad lleva asociado un 
conjunto de sensores que pueden ser accedidos, activados y desac- 
tivados no individualmente sino en conjunto. Debe ser posible 
definir hasta diez zonas de seguridad. Sea creativo, pero intente 
mantenerse dentro de lo definido para el panel de control del sis- 
tema tal y como fue definido previamente en este libro. 


21.6. Desarrolle un conjunto de casos de uso para el sistema 
SSRB del Problema 12.13. 


Tendrá que hacer varias suposiciones sobre la forma de 

interacción del usuario con el sistema. 

21.7. Desarrolle un conjunto de casos de uso para alguna de 

las siguientes aplicaciones: 

a) Software para un asistente personal electrónico de propó- 
sito general. 

b) Software para un videojuego de su elección. 

c) Software para el sistema de climatización de un auto- 
móvil. 

d) Software para un sistema de navegación de un automóvil. 

e) Un sistema propuesto por su instructor. 
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Lleve acabo una pequeña investigación(unas pocas horas) en 
el dominio de la aplicación y conduzca una reunión TFEA 
(Capítulo 11) con sus compañeros para desarrollarunos requi- 
sitos básicos (su instructor le ayudará a coordinarlo). 

21.8. Desarrolle un conjunto completo de tarjetas CRC del 
producto o sistema elegido en el problema anterior. 


21.9. Dirija una revisión de las tarjetas CRC con sus colegas. 
¿Cuántas clases, responsabilidades y colaboraciones adicio- 
nales ha añadido a consecuencia de la reunión? 

21.10. Desarrolle una jerarquía de clases para el producto o 
sistema elegido en el Problema 21.7. 

21.11.Desarrolle un conjunto de subsistemas (paquetes) para 
el producto o sistema elegido en el Problema 21.7. 

21.12. Desarrolle un modelo objeto-relación para el producto 
o sistema elegido en el Problema 21.7. 


21.13. Desarrolle un modelo objeto-comportamiento para el 
producto o sistema elegido en el problema 21.7. Asegúrese de 
listartodos los sucesos, proporcionarla traza de sucesos, desa- 
rrollar un diagrama de flujo de sucesos y definir diagramas de 
estado para cada clase. 


21.14. Describa con sus propias palabras la forma de deter- 
minar los colaboradores de una clase. 


21.15. ¿Qué estrategia propondría para definir subsistemasen 
colecciones de clases? 


21.16. ¿Qué papel desempeña la cardinalidad en el desarrollo 
de un modelo objeto-relación? 


21.17. ¿Cuál es la diferencia entre los estados pasivo y activo 
de un objeto? 


Los casos de uso forman la base del análisis orientado a obje- 
tos, sin importar el método de AOO elegido. Los libros de 
Rosemberg y Scott (Use case driven Object modelling with 
UML: a practical approach, Addison-Wesley,1999), Schnei- 
der, Vinters y Jacobson (Applying Use Cases: A Practical Gui- 
de, Addison-Wesley, 1999), y Texel y Williams (Use Cases 
Combined WithBooch/OMT/IUML: Process and Products, Pren- 
tice-Hall, 1997) proporciona una guía para la creación y uso 
de esta importante herramienta de obtención de requisitos y 
mecanismo de representación. 

Casi todos los libros publicados recientemente sobre aná- 
lisis y diseño orientado a objetos ponderan UML. Todos los 
que están considerando en serio aplicar UML en su trabajo, 
deberían comprar [BOO99], [JAC99] y [RUMO99]. Además 
de estos, los siguientes libros también son representativos de 
las docenas de ellos escritos sobre la tecnología de UML: 


Douglas, B., y Booch, G., Doing Hard Time: Developing Real- 


Time Systems with UML, Objects, Frameworks and Pat- 
terns, Addison-Wesley, 1999, 
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Douglas, B., Real-Time UML: Developing Efficient Objects 
for Embedded Systems, Addison-Wesley, 1999, 


Fowler, M., y Kendall Scott, UMLDistilled, 2.* ed., Addison- 
Wesley, 2000. 


Larman, C., Applying UML and Patterns: an Introductionto 
Object Oriented Analysis, Prentice-Hall, 1997. 


Odell, J.J., y Fowler, M., Advanced Object Oriented Analy- 
sis and Design Using UML, SIGS Books, 1998. 


Ostereich,B., Developing Software with UML: Object Orien- 
ted Analysis and Design inPractice, Addison-Wesley,1999, 


Page-Jones, M., Fundamentals of Object-Oriented Design in 

UML, Addison-Wesley, 1999. 

Stevens, P., y Pooley, R., Software Engineering with 
Objects and Components, Addison-Wesley, 1999. 

En Intemet hay gran cantidad de fuentes de información sobre 
análisis orientado a objetos y temas relacionados. Una lista actua- 
lizada sobre las referencias web relevantes de cara al análisis 
orientado a objetos la encontraráen http://www.pressman5.com 
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CAPÍTULO 
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DISEÑO ORIENTADO A OBJETOS 


L diseño orientado a objetos transforma el modelo de análisis creado usando análisis 

orientado a objetos (Capítulo 21), en un modelo de diseño que sirve como anteproyecto 

para la construcción de software. El trabajo de diseñador de software puede ser intimi- 
dante, Gamma y sus colegas [GAM95] proveen un panorama razonablemente exacto del DOO 
cuando declaran que: 


El diseño de software orientado a objetos es difícil, y el diseño de software reusable orientado a obje- 
tos es aun más difícil. Se deben identificar los objetos pertinentes, clasificarlos dentro de las clases en la 
granularidad correcta, definir interfaces de clases y jerarquías de herencia y establecer relaciones clave entre 
ellos. El diseño debe ser específico al problema que se tiene entre manos, pero suficientemente general para 
adaptarse a problemas y requerimientos futuros. Además se deberá evitar el rediseño, o por lo menos mini- 
mizarlo. Los diseñadores experimentados en OO dicen que un diseño reusable y flexible es difícil, si no 
imposible de obtener «bien», la primera vez. Antes de que un diseño sea terminado, usualmente tratan de 
reutilizarlo varias veces, modificándolo cada vez. 


A diferencia de los métodos de diseño de software convencionales, el DOO proporciona un 
diseño que alcanza diferentes niveles de modularidad. La mayoría de los componentes de un sis- 
tema, están organizados en subsistemas, un «módulo» a nivel del sistema. Los datos y las ope- 
raciones que manipulan los datos se encapsulan en objetos —una forma modular que es el bloque 
de construcción de un sistema OO—. Además, el DOO debe describir la organización específi- 
ca de los datos de los atributos y el detalle procedural de cada operación. Estos representan datos 
y piezas algorítmicas de un sistema OO y son los que contribuyen a la modularidad global. 


VISTAZO RÁPIDO 


¿Qué es? El diseño de software Orientado 


a objetos requiere la definición de una 
arquitectura de software multicapa, la 
especificaciónde subsistemas que rea- 
lizan funciones necesarias y proveen 
soporte de infraestructura, una descrip- 
ción de objetos (clases),que son los blo- 
ques de construccióndel sistema, y una 
descripciónde los mecanismosde comu- 
nicación, que permiten que los datos Bu- 
yan entre las capas, subsistemas y 
objetos. El Diseño Orientado a Objetos 
(DOO), cumple todos estos requisitos. 


¿Quién lo hace? El DOO lo realiza un 


ingeniero de software. 


¿Por qué es importante? Un sistema 


orientado a objetos utiliza las definicio- 
nes de las clases derivadas del modelo 
de análisis. Algunas de estas definicio- 
nes tendrán que ser construidas desde 


el principio, pero muchas otras pueden 
ser reutilizadas, si se reconocen los 
patrones de diseño apropiados. El DOO 
establece un anteproyecto de diseño,que 
permite al ingeniero de software definir 
la arquitectura OO, en forma que maxi- 
mice la reutilización; de esta manera, se 
mejora la velocidad del desarrollo y la 
calidad del producto terminado. 


¿Cuáles son los pasos? El DOO se divide 


en dos grandes actividades: diseño del 
sistema y diseño de objetos. El diseño de 
sistema crea la arquitectura del produc- 
to definiendo una serie de «capas», que 
cumplen funcionesespecíficas del siste- 
ma eidentificalas clases, quesonencap- 
suladas por los subsistemasqueresiden 
en cadacapa. 


Además, el diseño de sistemas incor- 
pora la especificación de tres compo- 


nentes: la interfazde usuario, la gestión 
de datos y los mecanismos de adminis- 
tración de tareas. El diseño de objetos se 
centra en los detalles internos de cada 
clase, definición de atributos. operacio- 
nes y detalles de los mensqes. 


¿Cuál esel produsto obtenido? El mode- 


lo de diseño OO abarca arquitectura de 
software, descripción de la interfaz de 
usuario, componentes de gestión de 
datos. mecanismos de administración de 
tareas y descripciones detalladas de cada 
una de las clases usadas en el sistema. 


¿Cómo puedo estar seguro de quelo 


he hecho correctamente? En cada 
etapa, los elementos del modelo de 
diseño orientado a objetos son revisa- 
dos por claridad, corrección, integridad 
y consistencia con los requisitos del 
cliente y entre ellos. 


La naturaleza Única del diseño orientado a objetos, reside en su capacidad para construir cua- 
tro conceptos importantes de diseño de software: abstracción, ocultamiento (ocultación) de 
información, independencia funcional y modularidad (Capítulo 13). Todos los métodos de dise- 
ño procuran software que exhiba estas características fundamentales, pero sólo el DOO provee 
un mecanismo que permite al diseñador alcanzar las cuatro, sin complejidad ni compromiso. 

El diseño orientado a objetos, la programación orientada a objetos, y las pruebas orientadas 
a objetos son actividades de construcción para sistemas OO. En este capítulo se considera el 
primer paso en la construcción. 
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sE 


En el Capítulo 13 se introdujo el concepto de una pirá- 
mide de diseño para el software convencional. Cuatro 
capas de diseño --datos, arquitectura, interfaz y nivel 
de componentes — fueron definidas y discutidas. Para 
sistemas orientados a objetos, podemos también definir 
una pirámide, pero las capas son un poco diferentes. 
Refiriéndose a la Figura 22.1, las cuatro capas de la pirá- 
mide de diseño VO son: 


La capa subsistema. Contiene una representación 
de cada uno de los subsistemas, para permitir al soft- 
ware conseguir sus requisitos definidos por el cliente e 
implementar la infraestructura que soporte los requeri- 
mientos del cliente. 


, configuromos el sistema 
amos su formo... 
son, Grady Booch y James Rumbuugh. 


La capa de clases y objetos. Contiene la jerarquía 
de clases, que permiten al sistema ser creado usando 
generalizaciones y cada vez especializacionesmás acer- 
tadas. Esta capa también contiene representaciones. 


La capa de mensajes. Contiene detalles de diseño, 
que permite a cada objeto comunicarse con sus colabo- 
radores. Esta capa establece interfaces externas e inter- 
nas para el sistema. 


La capa de responsabilidades. Contiene estructu- 


ras de datos y diseños algorítmicos, para todos los atri- 
butos y operaciones de cada objeto. 


Diseño 
de mensajes 


FIGURA 22.1. La pirámide del Diseño 00. 


La pirámide de diseño se centia exclusivamente en el 
diseño de un producto o sistema específico. Observe, sin 
embargo, que existe otra capa de diseño, y que esta capa 
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forma los cimientos sobre los que la pirámide se sostie- 
ne. La capa fundamental se centra en el diseño de los obje- 
tos del dominio (lamadospatrones de diseño). Los objetos 
del dominiojuegan un papel clave, en la construcción de 
la infraestructura del sistema OO aportando soporte para 
las actividades de interfaz hombre/máquina, administra- 
ción (gestión) de tareas y gestión (administración)de datos. 
Los objetos del dominio se pueden usar, además, para 
desarrollarel diseño de la aplicación en sí misma. 


22.1.1. Enfoque convencional vs. OO 


Los enfoques convencionalespara el diseño de software 
aplican distintas notaciones y conjunto de heurísticas, 
para trazar el modelo de análisis en un modelo de dise- 
ño. Recordandola Figura 13.1,cada elemento del mode- 
lo convencional de análisis se corresponde con uno o 
más capas del modelo de diseño. Al igual que el dise- 
ño convencional de software, el DOO aplica el diseño 
de datos cuando los atributos son representados, el di- 
seño de interfaz cuando se desarrolla un modelo de 
mensajería, y diseño a nivel de componentes (procedi- 
mental), para operaciones de diseño. Es importante notar 
que la arquitectura de un diseño OO tiene más que ver 
con la colaboración entre objetos que con el control de 
flujo entre componentes del sistema. 

A pesar de que existen similitudes entre los diseños 
convencionales y OO,se ha optado por renombrar las 
capas de la pirámide de diseño, para reflejar con mayor 
precisión la naturaleza de un diseño OO. La Figura 22.2 
ilustra la relación entre el modelo de análisis VO (Capí- 
tulo 21) y el modelo de diseño que se derivará de ahí. 


de tarjetas 
cac 


de comportamiento 


de objetos 


El modelo 
de análisis 


Diseñ 
de mensajes 


El modelo de diseño 


FIGURA 22.2. Transformación de un modelo de análisis OO 
a un modelo de diseño 00. 


1 Es importante hacer notar que la derivación no es siempre 
evidente. Para profundizar véase [DAV95]. 
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El diseño de subsistemas se deriva considerando los 
requerimientos globales del cliente (representados por 
los casos de uso) y los sucesos y estados que son exter- 
namente observables (el modelo de comportamiento de 
objetos). El diseño de clases y objetos es trazado de la 
descripción de atributos, operaciones y colaboraciones 
contenidasen el modelo CRC. El diseño de mensajes es 
manejado por el modelo objeto-relación, y el diseño de 
responsabilidades es derivado del uso de atributos, ope- 
raciones y colaboraciones descrito en el modelo CRC. 

Fichman y Kemerer [FIC92] sugieren diez compo- 
nentes de diseño modelado, que pueden usarse para com- 
parar varios métodos convencionales y orientados a 
objetos: 

1, representación de la jerarquía de módulos. 
2. especificación de las definiciones de datos. 
3. especificación de la lógica procedimental. 


4. indicación de secuencias de proceso final-a-final 
(end-to-end) 

5. representación de estados y transiciones de los 
objetos. 

6. definición de clases y jerarquías. 

7. asignación de operaciones a las clases. 

8. definición detallada de operaciones. 

9. especificación de conexiones de mensajes. 

10. identificación de servicios exclusivos. 


¿Qué criterio se puede usar 
para comparar los métodos 
convencionales y los métodos 
de DOO? 


Ya que existen muchos enfoques de diseño conven- 
cionales y orientados a objetos, es difícil desarrollar una 
comparación generalizada entre los dos métodos. Sin 
embargo, se puede asegurar que las componentes de 
modelado 5 al 10 no están soportadas usando diseño 
estructurado (Capítulo 14)o sus derivados. 


2.12. Aspectos del diseño 


Bertrand Meyer [MEY90] sugiere cinco criterios para 
juzgar la capacidad de métodos de diseño para conse- 
guir modularidad, y los relaciona al diseño orientado a 
objetos: 

. descomponibilidad: la facilidad con que un método 
de diseño ayuda al diseñador a descomponer un pro- 
blema grande en problemas más pequeños, hacién- 
dolos más fácil de resolver. 

componibilidad el grado con el que un método de 
diseño asegura que los componentes del programa 
(módulos), una vez diseñados y construidos, pueden 
ser reutilizados para crear otros sistemas. 
comprensibilidad la facilidad con la que el compo- 
nente de un programa puede ser entendido, sin hacer 
referencia a otra información o módulos. 
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continuidad: la habilidad para hacer pequeños cam- 
bios en un programa y que se revelen haciendo los 
cambios pertinentes en uno o muy pocos módulos. 
. protección: una característica arquitectónica, que 
reduce la propagación de efectos colaterales, si ocu- 
rre un error en un módulo dado. 


Referencia Web 


Una referencia que responde a la pregunta ¿qué hace 
que un diseño orientado o objetos sea bueno?, puede 
encontrarse en: www.kinetica.com /ootips /ood- 
principles.html 


De estos criterios, Meyer [MEY90], sugiere cinco 
principios básicos de diseño, que pueden ser deducidos 
para arquitecturas modulares: (1) unidades lingiísticas 
modulares, (2) pocas interfaces, (3) pequeñas interfa- 
ces (acoplamiento débil), (4) interfaces explícitas y (5) 
ocultación de información. 


: ¿Qué principios básicos 
nos guían en el diseño 
de arquitecturas modulares? 


Los módulos se definen como unidades lingilísticas 
modulares, cuando «corresponden a unidades sintácti- 
cas en el lenguaje usado» [MEY90]. Es decir, el len- 
guaje de programación que se usará debe ser capaz de 
definir directamente la modularidad. Por ejemplo, si el 
diseñador crea una subrutina, cualquiera de los lengua- 
jes de programación antiguos (FORTRAN, C, Pascal), 
debe poder implementarlos como una unidad sintácti- 
ca. Pero si un paquete que contiene estructuras de datos 
y procedimientos, y los identifica como una sola uni- 
dad definida, en un lenguaje como Ada (u otro lengua- 
je orientado a objetos), será necesario representar 
directamente este tipo de componente en la sintaxis del 
lenguaje. 

Para lograr el bajo acoplamiento (un concepto de 
diseño introducido en el Capítulo 13), el número de 
interfaces entre módulos debe minimizarse («pocas 
interfaces»), y la cantidad de información que se mue- 
ve a través de la interfaz también debe ser minimizada 
(«pequeñas interfaces»). Siempre que los componentes 
se comunican, deben hacerlo de manera obvia y direc- 
ta («interfaces explícitas»). Por ejemplo, si el compo- 
nente X y el componente Y se comunican mediante el 
área de datos global (a lo que se llama acoplamiento 
común en el Capítulo 13), violan el principio de inter- 
faces explícitas porque la comunicación entre compo- 
nentes no es obvia a un observadorexterno. Finalmente, 
se logra el principio de ocultamiento de información, 
cuando toda información acerca de un componente se 
oculta al acceso externo, a menos que esa información 
sea específicamente definida como pública. 
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Los criterios y principios de diseño presentados en 
esta sección pueden ser aplicados a cualquier método 
de diseño (así como al diseño estructurado). Como se 
verá, el método de diseño orientado a objetos logra cada 
uno de los criterios más eficientemente que otros enfo- 
ques, y resulta en arquitecturas modulares, que cumplen 
efectivamente cada uno de los criterios. 


22.13. El Panorama de DOO 


Como se vio en el Capitulo 21, una gran variedad de 
métodos de análisis y diseño orientados a objetos fue 
propuesta y utilizada durante los ochenta y los noven- 
ta. Estos métodos establecieron los fundamentos para 
la notación moderna de DOO, heurísticas de diseño y 
modelos. A continuación, haremos una breve revisión 
global de los primeros métodos de DOO: 


El método de Booch. Como se vio en el Capítulo 
21, el método Booch [BOO94] abarca un «proceso de 
micro desarrollo» y un «proceso de macro desarrollo». 
En el contexto del diseño, el macro desarrollo engloba 
una actividad de planificación arquitectónica, que agrupa 
objetos similares en particiones arquitectónicas separa- 
das, capas de objetos por nivel de abstracción, identi- 
fica situaciones relevantes, crea un prototipo de diseño 
y valida el prototipo aplicándolo a situaciones de uso. 
El micro desarrollo define un conjunto de «reglas» que 
regulan el uso de operaciones y atributos y las políticas 
del dominio específico para la administración de la 
memoria, manejo de errores y otras funciones; desa- 
rrolla situaciones que describen la semántica de las 
reglas y políticas; crea un prototipo para cada política; 
instrumenta y refina el prototipo; y revisa cada política 
para así «transmitir su visión arquitectónica»[B0094], 


Ja que la transición de la fase de 
diseño no deberío ser más fácil en 
sofhwate que en cualquier otra 

ña. El diseño es difícil. 


El método de Rumbaugh. La técnica de modelado 
de objetos (TMO) [RUMO91] engloba una actividad de 
diseño que alienta al diseño a ser conducido a dos dife- 
rentes niveles de abstracción. El diseño de sistema se 
centra en el esquema de los componentes que se nece- 
sitan para construir un sistema o producto completo. 
El modelo de análisis se divide en subsistemas, los 
cuales se asignan a procesadores y tareas. Se define 
una estrategia para implementar la administración de 
datos, y se identifican los recursos y mecanismos de 
control requeridos para accesarlos. El diseño de obje- 


2 Un bloque es la abstracción de diseño, que permite la representa- 
ción de un objeto agregado. 
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tos enfatiza el esquema detallado de un objeto indivi- 
dual. Se seleccionan las operaciones del modelo de 
análisis, y los algoritmos se definen para cada opera- 
ción. Se representan las estructuras de datos apropia- 
das para atributos y algoritmos. Las clases y atributos 
de clase son diseñados de manera que se optimice el 
acceso a los datos, y se mejore la eficiencia computa- 
cional. Se crea un modelo de mensajería, para imple- 
mentar relaciones de objetos (asociaciones). 


El método de Jacobson. El diseño para ISOO 
(Ingeniería del software orientada a objetos) [JAC92] 
es una versión simplificada del método propietario 
Objectory, también desarrollado por Jacobson. El 
modelo de diseño enfatiza la planificación para el 
modelo de análisis ISOO. En principio, el modelo 
idealizado de análisis se adapta para acoplarse al 
ambiente del mundo real. Después los objetos de 
diseño primarios, llamados bloques”, son creados y 
catalogados como bloques de interfaz, bloques de enti- 
dades y bloques de control. La comunicación entre 
bloques durante la ejecución se define y los bloques 
se organizan en subsistemas. 


El método de Coad y Yourdon. Éste método para 
DOO [COA91], se desarrolló estudiando «cómo es que 
los diseñadores orientados a objetos efectivos» hacen 
su trabajo. La aproximación de diseño dirige no sólo la 
aplicación, sino también la infraestructura de la aplica- 
ción, y se enfoca en la representación de cuatro com- 
ponentes mayores de sistemas: la componente de 
dominio del problema, la componente de interacción 
humana, la componente de administración de tareas y 
la de administración de datos. 


El método de Wirfs-Brock. Wirfs-Brock, Wilker- 
son y Weiner [WIR90] definen un conjunto de tareas 
técnicas, en la cual el análisis conduce sin duda al diseño. 
Los protocolos? para cada clase se construyen refinando 
contratos entre objetos. Cada operación (responsabili- 
dad) y protocolo (diseño de interfaz) se diseña hasta un 
nivel de detalle que guiará la implementación. Se desa- 
rrollan las especificaciones para cada clase (definirres- 
ponsabilidades privadas y detalles de operaciones) y 
cada subsistema (identificar las clases encapsuladas y 
la interacción entre subsistemas). 


Rions:of) 


Aunque no es tan robusto como UML, el método Wirfs- 
Brock tiene uno elegancia sencilla, que lo convierte 
en un enfoquealterativo e interesante ol DOO. 


A pesar de que la terminología y etapas de proceso 
para cada uno de estos métodos de DOO difieren, los 
procesos de DOO global son bastante consistentes. 


3 Un protocolo es una descripción formal de los mensajes, a los que 
la clase responde. 
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Para llevar a cabo un diseño orientado a objetos, un 
ingeniero de software debe ejecutar las siguientes eta- 
pas generales: 


1, Describir cada subsistema y asignar a procesadores 
y tareas. 


2. Elegir una estrategia para implementar la adminis- 
tración de datos, soporte de interfaz y administración 
de tareas. 


3. Diseñar un mecanismo de control, para el sistema 
apropiado. 

4. Diseñar objetos creando una representación proce- 
dural para cada operación, y estructuras de datos para 
los atributos de clase. 


5. Diseñar mensajes, usando la colaboraciónentre obje- 
tos y relaciones. 


6. Crear el modelo de mensajería. 


7. Revisar el modelo de diseño y renovarlo cada vez 
que se requiera. 


e 
CLA VE 


Un conjunto de etapas genéricas se aplica durante 
el DOO, sin importar el método de diseño que se escoja. 


Es importante hacer notar que las etapas de diseño 
discutidas en esta sección son iterativas. Eso significa 
que deben ser ejecutadas incrementalmente, junto con 
las actividades de AOO, hasta que se produzca el dise- 
ño completo. 


22.1.4. Un enfoque unificado para el DOO 


En el Capítulo 21, se mencionó como Grady Booch, 
James Rumbaugh e Ivar Jacobson, combinaron las 
mejores cualidades de sus métodos personales de aná- 
lisis y diseño orientado a objetos, en un método uni- 
ficado. El resultado, llamado el Lenguaje de Modelado 
Unificado, se ha vuelto ampliamente usado en la 
industria”, 


Referencia 


Un tutorial y listado extenso de recursos de UML incluyendo 
herramientas, referencias y ejemplos, 
se pueden encontrar en: mini.net/cetus/oo_uml.html 


Durante el modelo de análisis (Capítulo 21), se repre- 
sentan las vistas del modelo de usuario y estructural. 


4 Booch, Rumbaugh y Jacobson han escrito tres libros muy impor- 
tantes sobre UML. El lector interesado debe consultar [BOO99], 
[RUM99] y JAC99] 
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Estas proporcionaron una visión interna al uso de las 
situaciones para el sistema (facilitando guías para el 
modelado de comportamiento), y establecieron funda- 
mentos para la implementación y vistas del modelo 
ambiental, identificando y describiendo elementos 
estructurales estáticos del. sistema. 

UML se organiza en dos actividades mayores: 
diseño del sistema y diseño de objetos. El principal 
objetivo de UML, diseño de sistema, es representar 
la arquitectura de software. Bennett, Mc Robb y Far- 
mer [BEN99], exponen este aspecto de la siguiente 
manera: 


En términos de desarrollo orientado a objetos, la arqui- 
tectura conceptual está relacionada con la estructura del 
modelo estático de clase y las conexiones entre las com- 
ponentes del modelo. El modelo arquitectura describe la 
manera como el sistema se divide en subsistemas o módu- 
los, y como se comunican exportando e importando datos. 
La arquitectura de código, define como es que el código 
del programa se encuentra organizado en archivos y direc- 
torios y agrupado en librerías. La arquitectura de ejecución 
se centra en los aspectos dinámicos del sistema y la comu- 
nicación entre componentes, mientras las tareas y opera- 
ciones se ejecutan. 


La definición de «subsistemas», nombrada por Ben- 
nett et al., es una preocupación principal durante el dise- 
ño de sistema de UML. 


e, 
CLA VE 


B diseño de sistema se centra en arquitectura 
de softwore y definición de subsistemas. 

B diseño de objetos describe objetos, hasta 
un nivel en el cual puedan ser implementados, 
en un lenguaje de programación. 


El diseño de objetos se centra en la descripción de 
objetos y sus interacciones con los otros. Una especifi- 
cación detallada de las estructuras de datos de los atri- 
butos y diseño procedural de todas las operaciones, se 
crea durante el diseño de objetos. La visibilidad” para 
todos los atributos de clase se define, y las interfaces 
entre objetos se elaboran para definir los detalles de un 
modelo completo de mensajes. 

El diseño de sistemas y objetos en UML se extien- 
de para considerar el diseño de interfaces, adminis- 
tración de datos con el sistema que se va a construir 
y administración de tareas para los subsistemas que 
se han especificado. La interfaz de usuario en UML 
utiliza los mismos conceptos y principios examina- 
dos en el Capítulo 15. La visión del modelo de usua- 


5 Visibilidad indica si el atributo es público (disponible a través de 
todas las instancias de la clase),privado (disponible sólo para la clase 
que lo especifica) o protegido (un atributo que puede ser usado por 
la clase que lo especifica y por sus subclases). 
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rio maneja el proceso del diseño de la interfaz de 
usuario, proporcionando una situación que se elabo- 
ra iterativamente, para volverse un conjunto de cla- 
ses de interfaz”, La administración de datos establece 
un conjunto de clases y colaboraciones, que permi- 
ten al sistema (producto) manejar datos persistentes 
(por ejemplo, archivos y bases de datos). El diseño 
de la administración de tareas establece la infraes- 
tructura que organiza subsistemas en tareas, y admi- 
nistra la concurrencia de tareas. El flujo de procesos 
para el diseño se ilustra en la Figura 22.3”. 

A lo largo del proceso de diseño UML, la visión del 
modelo de usuario y de estructura se elabora dentro del 
diseño de la representación delimitada anteriormente. 
Esta actividad de elaboración se analiza en las seccio- 
nes siguientes. 


Análisis 
orientado 
a objetos 


Diseño 
del sistema 


Diseño 
de la gestión 
de tareas 


Diseño 
de objetos 


Diseño 
de la gestión 
de datos 


Diseño 
de la interfaz 
humana 


FIGURA 22.3.Flujo de Proceso para DOO. 


El diseño de sistema desarrolla el detalle arquitectóni- 
co requerido para construir un sistema o producto. El 
proceso de diseño del sistema abarca las siguientes acti- 
vidades: 


Partición del modelo de análisis en subsistemas. 
Identificar la concurrencia dictada por el problema. 


Asignar subsistemas a procesadores y tareas. 
Desarrollar un diseño para la interfaz de usuario. 
Elegir una estrategia básica para implementar la 
administración (gestión) de datos. 

Identificar recursos globales y los mecanismos de 
control requeridos para su acceso. 


Cuáles son las etapas 
del proceso de diseño 
de sistemas? 


Diseñar un mecanismo de control apropiado para el 
sistema, incluyendo administración de tareas. 
Considerar cómo deben manejarse las condiciones 
de frontera. 


Revisar y considerar trade-offs. 

En las secciones siguientes, el diseño de actividades 
relacionadas con cada una de estas etapas se conside- 
ran con mayor detalle. 


22.2.1. Particionar el modelo de análisis 


Uno de los principios fundamentales del análisis (Capí- 
tulo 11)es hacer particiones. En el diseño de sistemas OO 


6 Hoy en día la mayoría de las clases de interfaz son parte de una 
librería de componentes de software reutilizables. Esto facilita el 
diseño e implementación de IGUs (Interfaz gráfica de usuario). 
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particiona el modelo de análisis, para definir colecciones 
congruentes de clases, relaciones y comportamiento. Estos 
elementos de diseño se definen como subsistema. 


Cons: 


las conceptos de cohesión y acoplamiento (Capítulo 131 
pueden aplicarse o nivel de subsistemas. Esfuércese 

par alcanzar uno buena independencia funcional, 

cuando diseñe subsistemas 


En general, todos los elementos de un subsistema 
comparten alguna propiedad en común. Y se integran 
para completar la misma función; deben residir dentro 
del mismo producto de hardware, o deben administrar 
la misma clase de recursos. Los subsistemas se caracte- 
rizanpor sus responsabilidades; eso significaque un sub- 
sistema puede identificarsepor los servicios que provee 
[RUM091]. Cuando se usa en el contexto de un diseño de 
sistema OO, un servicio es una colección de operacio- 
nes que llevan a cabo una función específica (por ejem- 
plo, administrar archivos de procesador de textos, 
producir un rendering tridimensional, traducir una señal 
de vídeo analógica en una imagen digital comprimida). 


|, ¿Qué criterios nos guían 
en el diseño de subsistemas? 


Cuando se definen (y diseñan) los subsistemas, se 
deben seguir los siguientes criterios de diseño: 
El subsistema debe tener una interfaz bien definida, 
a través de la cual se reduzcan todas las comunica- 
ciones con el resto del sistema. 


7 Recuerde que el AOO es una actividad iterativa. Es totalmente posi- 
ble que el modelo de análisis sea revisado como consecuencia del 
trabajo de diseño. 
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+. Con la excepción de un pequeño número de «clases 
de comunicación», las clases incluidas dentro del 
subsistema deben colaborar sólo con otras clases den- 
tro del subsistema. 

El número de subsistemas debe ser bajo. 

Un subsistema puede ser particionado internamente, 
para ayudar a reducir la complejidad. 

Cuando dos subsistemas se comunican entre sí, pue- 
den establecer un enlace clientelservidor o un enlace 
punto-a-punto (peer-to-peer) [RUM91]. En un enlace 
cliente/servidor, cada uno de los subsistemas asume uno 
de los papeles implicados, el de el cliente o el del ser- 
vidor. El servicio fluye del servidor al cliente en una 
sola dirección. En un enlace punto-a-punto, los servi- 
cios pueden fluir en cualquier dirección. 

Cuando un sistema es particionado en subsistemas, 
se lleva a cabo otra actividad de diseño, llamada estra- 
tificación por capas. Cada capa [BUS96] de un sistema 
00, contiene uno o más subsistemas y representa un 
nivel diferente de abstracción de la funcionalidadreque- 
rida para completar las funciones del sistema. En la 
mayoría de los casos, los niveles de abstracción se deter- 
minan por el grado en que el procesamiento asociado 
con el subsistema es visible al usuario final. 

Por ejemplo, una arquitectura de cuatro capas debe 
incluir: (1) una capa de presentación (el subsistema aso- 
ciado con la interfaz de usuario), (2) una capa de apli- 
cación (el subsistema que lleva a cabo procesos asociados 
con la aplicación), (3) una capa de formato de datos (los 
subsistemas que preparan los datos para ser procesados), 
y (4) una capa de base de datos (el subsistema asociado 
con la administración de datos). Cada capa se encuen- 
tra más profundamente dentro del sistema, representan- 
do un procesamiento más específico al ambiente. 


Cómo se crea un diseño 
por capas? 


Buschmann y sus colegas [BUS96] sugieren el 
siguiente enfoque de diseño para estratificación por capas: 
1. Establecer los criterios de estratificación por capas. 

Esto significa decidir cómo se agruparán los subsis- 
temas en una arquitectura de capas. 
. Determinar el número de capas. Muchas de ellas 
complican innecesariamente; muy pocas debilitan la 
independencia funcional. 
Nombrar las capas y asignar subsistemas (con sus 
clases encapsuladas) a una capa. Asegurarse de que 
la comunicación entre subsistemas (clases) en una 
capa?, y otros subsistemas (clases) en otra capa, 
siguen la filosofía de diseño de la arquitectura. 
. Diseñar interfaces para cada capa. 
. Refinar los subsistemas, para establecer la estructura 
de clases para cada capa. 


pe 


TS 


8 En una arquitectura cerrada, los mensajes procedentes de una 
capa se deberían haber enviado a la capa adyacente inferior. En 
una arquitectura abierta, los mensajes deben enviarse a cual- 
quiera de las capas inferiores. 
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6. Definir el modelo de mensajería para la comunica- 
ción entre capas. 


7. Revisar el diseño de capas, para asegurar que el aco- 
plamiento entre capas se minimiza (un protocolo 
cliente/servidor puede ayudar a realizar esta tarea) 


8. Iterar para refinar el diseño de capas. 


22.2.2. Asignación de concurrencia y subsistemas 


El aspecto dinámico del modelo objeto-comportamien- 
to provee una indicación de concurrencia entre clases (o 
subsistemas). Si las clases (o subsistemas) no se activan 
al mismo tiempo, no hay necesidad para el procesamiento 
concurrente. Esto significa que las clases (o subsistemas) 
pueden ser implementadas en el mismo procesador de 
hardware. Por otro lado, si las clases (o subsistemas) 
deben actuar en sucesos asincrónicamente y al mismo 
tiempo, se verán como concurrentes. Cuando los sub- 
sistemas son concurrentes, existen dos opciones de alo- 
jamiento: (1) alojar cada subsistema en procesadores 
independientes Ó (2) alojar los subsistemas en el mismo 
procesador y proporcionar soporte de concurrencia, sobre 
las características del sistema operativo. 


Consuof) 


En la mayoría de los casas, unaimplementación 

de multiproceso incrementola complejidad y el riesgo 
técnica. Siempre que sea posible, escoja lo arquitectura 
de procesador más simple que pueda realizar el trabajo. 


Las tareas concurrentes se definen [RUMO91] exa- 
minando el diagrama de estado para cada objeto. Si el 
flujo de sucesos y transiciones indica que solo un obje- 
to está activo en el tiempo, un hilo de control se ha esta- 
blecido. El hilo de control continúa, aun cuando un 
objeto envía un mensaje a otro objeto, mientras que el 
primer objeto espera por la respuesta. Sin embargo, si 
el primer objeto continúa procesando después de enviar 
un mensaje, el hilo de control se divide. 

Las tareas en un sistema OO se diseñan generando 
hilos de control aislados. Por ejemplo, mientras que el 
sistema de seguridad HogarSeguro monitoriza sus sen- 
sores, puede también marcar a la estación central de 
monitorización para verificar la conexión. Ya que los 
objetos involucrados en ambos comportamientos están 
activos al mismo tiempo, cada uno representa un hilo 
de control y cada uno puede ser definidocomo una tarea 
distinta. Si la monitorización y marcado ocurrieran 
secuencialmente, podría implementarse una sola tarea. 

Para determinar cuál de las opciones de asignación 
de procesadores es apropiada, el diseñador debe consi- 
derar los requisitos de desempeño, costos y el encabe- 
zado impuesto por la comunicación entre procesadores. 
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22.2.3. Componentede administraciónde tareas 


Coad y Yourdon [COA91] sugieren la estrategia siguien- 
te, para el diseño de objetos que manipulan tareas con- 
currentes: 


se determinan las características de la tarea. 


se define un coordinador de tarea y objetos asocia- 
dos. 

se integra el coordinador y otras tareas. 

Las características de la tarea se determinan, com- 
prendiendo cómo es que se inicia la tarea. Las tareas 
controladas por sucesos y manejadas por reloj son 
las más comunes. Ambas se activan por una inte- 
rrupción, pero la primera recibe una interrupción de 
alguna fuente externa (por ejemplo, otro procesador, 
un Sensor), mientras que la última es controlada por 
el reloj. 


Además de la manera en que una tarea es inicia- 
da, también se deben determinar la prioridad y cri- 
ticidad de la tarea. Las tareas de alta prioridad deben 
tener acceso inmediato a los recursos del sistema. 
Las tareas de alta criticidad deben continuar ope- 
rando aun cuando la disponibilidad de un recurso es 
reducida O el sistema operativo se encuentra en esta- 
do degradado. 

Una vez que las características de la tarea se han 
determinado, se definen los atributos y operaciones 
del objeto requerido, para alcanzar coordinación y 
comunicación con otras tareas. La plantilla básica de 
una tarea (para un objeto tarea), toma la forma de 


[COA91]: 


Nombre de la tarea - el nombre del objeto 
Descripción - un relato que describe el propósito 
del objeto. 

Prioridad - prioridad de la tarea (por ejemplo, alta, 
media, baja). 

Servicios - lista de operaciones que son responsa- 
bilidad del objeto. 

Coordinados por - la manera como se invoca el com- 
portamiento del objeto. 


Comunicados vía — datos de entrada y salida rele- 
vantes a la tarea. 


La descripción de esta plantilla puede ser traducida 
en el modelo de diseño estándar (incorporando la repre- 
sentación de atributos y operaciones), para los objetos 
tarea. 


22.2.4. Componente de interfaz de usuario 


Aunque la componente de interfaz de usuario se imple- 
menta dentro del contexto del dominio del problema, la 


386 


interfaz por sí misma representa un subsistema de impor- 
tancia crítica para la mayoría de las aplicaciones moder- 
nas. El modelo de análisis OO (Capítulo 21), contiene 
los escenarios de uso (llamados casos de uso), y una 
descripción de los roles que:juegan los usuarios (lla- 
mados actores) cuando interactúan con el sistema. Este 
modelo sirve como entrada al proceso de diseño de inter- 
faz de usuario. 


la mayoría de las clases necesarias para crear 

una interfaz moderna ya existen y están disponibles 
para el diseñador. B diseño de interfaz obedece 

al enfoque definida en el Capítulo 15. 


Una vez que el actor y su situación de uso se defi- 
nen se identifica una jerarquía de comando. La jerar- 
quía de órdenes define la mayoría de las categorías del 
menú de sistema (la barra de menú o la paleta de herra- 
mientas), y todas las subfunciones, que estarán dispo- 
nibles en el contexto de una categoría importante de 
menú de sistema (las ventanas de menú). La jerarquía 
de órdenes se refina repetidamente, hasta que cada caso 
de uso pueda ser implementado navegando por lajerar- 
quía de funciones. 

Debido a que existe una amplia variedad de entor- 
nos de desarrollo de interfaces de usuario, el diseño de 
los elementos de una IGU (Interfaz Gráfica de Usuario) 
no es necesario. Ya existen clases reutilizables (con atri- 
butos y operaciones apropiadas) para ventanas, iconos, 
operaciones de ratón y una amplia gama de otro tipo de 
funciones de interacción. La persona que implementa 
estas clases (el desarrollador), sólo necesita instanciar 
objetos, con las características apropiadas para el domi- 
nio del problema. 


22.2.5. Componente de la administración 
de datos 


La administración o gestión de datos engloba dos áre- 
as distintas de interés: (1) la administración (gestión) 
de datos críticos para la propia aplicación, y (2) la crea- 
ción de infraestructura para el almacenamiento y recu- 
peración de los objetos. En general, la administración 
de datos se diseña en forma de capas. La idea es aislar 
los requisitos de bajo nivel que manipulan las estructu- 
ras de dafos, de los requisitos de alto nivel para mane- 
jar los atributos del sistema. 

En el contexto del sistema, un sistema de manipula- 
ción de bases de datos, normalmente se usa como alma- 
cén de datos común para todos los subsistemas. Los 
objetos requeridos para manipular la base de datos son 
miembros de clases reutilizables que se identifican 
mediante el análisis del dominio (Capítulo 21), o que 
se proporcionan directamente por el fabricante de la 
base de datos. Una discusión detallada del diseño de 
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bases de datos para sistemas OO está fuera del ámbito 
de este libro”. 

El diseño de la componente de administración de 
datos incluye el diseño de los atributos y operaciones 
requeridas para administrar objetos. Los atributos sig- 
nificativos se añaden a cada objeto en el dominio del 
problema, y proporcionan información que responde a 
la pregunta «¿Cómo me almaceno?». Coad y Yourdon 
[COA91] aconsejan la creación de una clase objeto- 
servidor, «con los servicios de (a) indicar al objeto que 
se almacene a sí mismo, y (b) recuperar objetos alma- 
cenados para su uso por otros componentes de diseño». 

Como un ejemplo de la gestión de los datos para el 
objeto Sensor, examinado como parte del sistema de 
seguridad HogarSeguro, el diseño puede especificar un 
archivo llamado«Sensor». Cada registro debería corres- 
ponder a una instancia denominada Sensor, y habría de 
contener los valores de cada atributo de Sensor para una 
instancia dada. Las operaciones dentro de la clase objeto- 
servidor deberían permitir a un objeto específico ser 
almacenado y recuperado, cuando sea requerido por el 
sistema. Para objetos más complejos, sería necesario 
especificar una base de datos relacional, o una base de 
datos orientada a objetos para ejecutar la misma función. 


Solicitud 


Subsistema 
servidor 


Subsistema 
cliente 


Solicitud Subsistema 


punto 
(par-peer) 


Subsistema 
punto 


(par-peer) 


Solicitud 


FIGURA 22.4. Modelo de colaboración entre subsistemas. 


22.2.6. Componente de gestión de recursos 


Están disponibles una variedad de recursos diferentes 
para un sistema o producto OO; y, muchas veces, los 
subsistemas compiten por estos recursos al mismo tiem- 
po. Los recursos globales del sistema pueden ser enti- 
dades externas (por ejemplo, una unidad de disco, 
procesador o línea de comunicaciones) o abstracciones 
(por ejemplo, una base de datos, un objeto). Sin impor- 
tar la naturaleza del recurso, el ingeniero de software 


? Los lectores interesados deben consultar [BRO91], [TAY92] y 
[RAO94] 
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debe diseñar un mecanismo de control para ello. Rum- 
baugh y sus colegas [RUM91|] sugieren que cada recur- 
so deba ser poseído por un «objeto guardián». El objeto 
guardián es el portero del recurso, controlando el acce- 
so y moderando peticiones contradictorias para él. 


22.2.7. Comunicaciones entre subsistemas 


Una vez que cada subsistema ha sido especificado, es 
necesario definir las colaboraciones que existen entre 
subsistemas. El modelo que se usa para la colaboración 
objeto-objeto puede ser extendido en conjunto para los 
subsistemas. La Figura 22.4 ilustra un modelo de cola- 
boración. Como se vio anteriormente en este capítulo, 
la comunicación puede ocurrir estableciendo un enlace 
cliente/servidor O punto-a-punto. Refiriéndose a la Figu- 
ra, se debe especificar la interacción que existe entre 
subsistemas. Recuérdese que un contrato proporciona 
la indicación de los modos como un subsistema puede 
interactuar con otro. 


¿Qué etapas de diseño 
se requieren para especificar 
un «contrato» de un subsistema? 


Las siguientes etapas de diseño pueden aplicarse para 
especificar un contrato para un subsistema [WIR90]: 


1. Listar cada petición que puede ser realizadapor los 
colaboradores del subsistema. Organizar las peti- 
ciones por subsistema y definirlas dentro de uno o 
más contratos apropiados. Asegurarse de anotar con- 
tratos que se hereden de superclases. 

2 Para cada contrato, anotar las operaciones (las here- 
dadas y las privadas, ) que se requieren para imple- 
mentar las responsabilidades que implica el contrato. 
Asegurarse de asociar las operaciones con las clases 
específicas, que residen en el subsistema. 


Considerar un contrato a la vez, crear una tabla con 
laforma de la.Figura 22.5. Para cada contrato, la 
tabla debe incluir las siguientes columnas: 


Tipo: el tipo de contrato (por ejemplo, cliente/ 
servidor O punto-a-punto). 


Contrato | Tipo | Colaboradores] Clase(s) | Operación(es) 
del mensaje 


FIGURA 22.5. Tabla de colaboraciones del subsistema. 
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Colaboradores:los nombres de los subsiste- 
mas que son parte del contrato. 

Clase: los nombres de las clases (contenidas en 
el subsistema), que proporcionan servicios deno- 
tados por el contrato. 

Operaciones:nombres de las operaciones (den- 
tro de la clase), que implementan los servicios. 

Formato del mensaje: el formato del mensaje 
requerido para implementar la interacción entre 
colaboradores. 

Esboce una descripción apropiada del mensaje, 
para cada interacción entre los subsistemas. 

. Silos modos de interacción entre los subsistemas 

son complejos, debe crear un diagrama subsis- 

tema-colaboración como el de la Figura 22.6. El 


grafo de colaboración es similar, en forma, al dia- 
grama de flujo de sucesos examinado en el Capí- 
tulo 21. Cada subsistema se representa, junto con 
sus interacciones con otros subsistemas. Los con- 
tratos que se invocan durante interacción, se deta- 
llan como se muestra en la Figura. Los detalles 
de la interacción se determinan observando el con- 
trato en la tabla de colaboración del subsistema 
(Fig. 22.5). 


SN 
a 


CLAVE 


Coda contrato entre suossiema se mantiesto por uno o 


mós mensajes que se transportan entre los objetos dentro 
de los suossiemos 


> 


Retomando la metáfora que se introdujo al inicio del 
libro, el diseño de sistemas OO se puede visualizar como 
el plano del suelo de una casa. El plano del suelo espe- 
cifica el propósito de cada habitación y sus caracterís- 
ticas arquitectónicas, que conectan las habitaciones unas 
con otras y con el ambiente exterior. Ahora es el momen- 
to de proporcionar los detalles que se requieren, para 
construir cada habitación. En el contexto del DOO, el 
diseño de objetos se centra en las «habitaciones». 

Bennet y sus colegas [BEN99] examinan el diseño 
de objetos de la siguiente manera: 

El diseño de objetos tiene que ver con el diseño detallado 
de los objetos y sus interacciones. Se completa dentro de la 
arquitecturaglobal, definida durante el diseño del sistema y de 
acuerdo con las reglas y protocolos de diseño aceptados. El 
diseño del objeto está relacionado en particular con la especi- 
ficación de los tipos de atributos, cómo funcionan las opera- 
ciones y cómo los objetos se enlazan con otros objetos. 


Es en esta fase cuando los principios y conceptos 
básicos asociados con el diseño a nivel de componen- 
tes (Capítulo 16) entran enjuego. Se definen las estruc- 
turas de datos locales (para atributos), y se diseñan los 
algoritmos (para operaciones). 


22.3.1. Descripción de objetos 


Una descripción del diseño de un objeto (instancia de 
clase o subclase) puede tomar una o dos formas 
[GOL83]: (1) Una descripción de protocolo que esta- 
blece la interfaz de un objeto, definiendo cada mensaje 
que el objeto puede recibir y las operaciones que el obje- 
to lleva a cabo cuando recibe un mensaje, o (2) Unades- 
cripción de implementación que muestra detalles de 
implementación para cada operación implicada por un 
mensaje pasado a un objeto. Los detalles de imple- 
mentación incluyen información acerca de la parte pri- 
vada del objeto; esto significa, detalles internos acerca 
de la estructura de datos, que describen los atributos del 


388 


objeto, y detalles de procedimientos, que describen las 
Operaciones. 


Consuofh 


Asegúrese de que lo arquitectura se ha definido 
antes de comenzar e diseño de objetos. No deje 
que lo arquitecturapredomine. 


La descripción del protocolo no es nada más que un 
conjunto de mensajes y un comentario correspondien- 
te para cada mensaje. Por ejemplo, una porción del pro- 
tocolo de descripción para el objeto sensor de 
movimiento (descrito anteriormente), podría ser: 


MENSAJE (sensor.movimiento) —> leer: DEVUELVE sen- 
sor.ID, sensor.estado; 


Esto describe el mensaje requerido para leer el Sen- 
sor. Igualmente, 


MENSAJE (sensormovimiento) --> asigna: ENVIA sen- 
sor.ID, sensor.estado; 


Asigna (establece) o inicializa el estado del Sensor. 


Subsistema 
para el panel 
de control 


Subsistema 
sensor 


Solicitud de asignación 
de estado para la zona 


Solicitud de de estado de prueba 
especificación 

del tipo de _ _ 
chequeo Solicitud de notificación 


periódico periódica del chequeo 
de estado de actualización de la 
de la alarma configuración de alarma 
del sistema Subsistema 


central 
de 
comunicación 


FIGURA 22.6. Gráfico abreviado del subsistema colaborado 
de HogarSeguro. 
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Para un sistema grande con muchos mensajes, gene- 
ralmente es posible crear categorías de mensajes. Por 
ejemplo, categorías de mensajes para el objeto Sistema 
de HogarSeguro deberían incluir mensajes de configu- 
ración del sistema, mensajes de monitorización (super- 
visión), mensajes de sucesos, etc. 

Una descripción de la implementación de un objeto, 
proporciona los detalles internos («ocultos»), que se 
requieren para la implementación, pero no son necesa- 
rios para ser invocados. Esto significa que el diseñador 
del objeto debe proporcionar una descripción de imple- 
mentación, y debe por tanto crear los detalles internos 
del objeto. Sin embargo, otro diseñador o desarrollador 
que utilice el objeto u otras instancias del objeto, requie- 
re solo la descripción del protocolo, pero no la descrip- 
ción de la implementación. 

Una descripción de la implementación se compone de 
la siguiente información: (1) una especificación del nom- 
bre del objeto y referencia a la clase; (2) una especifica- 
ción de las estructuras de datos privadas, con indicación 
de los datos y sus respectivos tipos; (3) una descripción 
de procedimientos de cada operación o, alternativamen- 
te, indicadores a dichas descripciones de procedimien- 
tos. La descripción de implementación debe contener 
información suficiente,para el manejo adecuado de todos 
los mensajes descritos en la descripción de protocolo. 


a 
SS 


CLAVE 


Para alcanzar los beneficios del ocultamiento 

de información (Capítulo 13), cualquiera que intente 
usar un objeto solo necesita la descripción 

del protocolo. La descripción de la implementación 
contiene detalles, que deberían «ocultarse» 

de aquellos que no tienen necesidad de conocer. 


Cox [COX85] caracteriza la diferencia entre la infor- 
mación contenida en la descripción de protocolo y la 
contenida en la descripción de implementación, en tér- 
minos de «usuarios» y «proveedores» de servicios. Un 
«usuario» del servicio provisto por un objeto debe ser 
familiar con el protocolo de invocación del servicio; eso 
significa especificar lo que se desea. El proveedor del 
servicio (el propio objeto), debe ocuparse del modo en 
que el servicio se suministrará al usuario; eso significa 
con detalles de implementación. 


22.3.2. Diseño de algoritmos y estructuras 
de datos 


Una variedad de representacionescontenidas en el mode- 
lo de análisis y el diseño de sistema, proveen una espe- 
cificación para todas las operaciones y atributos. Los 
algoritmos y estructuras de datos se diseñan utilizando 
un enfoque, que difiere un poco de los enfoques del dise- 
ño de datos y del diseño a nivel de componentes exa- 
minadas para la ingeniería del software convencional. 
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Referencia cruzada 


Aporentemente, cada concepto que se presentó 
en el Capítulo 13 es también aplicable aquí. 
Asegúrese de estar familiarizado con los temas 
presentados en el Capítulo 13, 


Se crea un algoritmo para implementar la especifi- 
cación para cada operación. En muchas ocasiones, el 
algoritmo es una simple secuenciacomputacional o pro- 
cedural, que puede ser implementada como un módulo 
de software autocontenido. Sin embargo, si la especifi- 
cación de la operación es compleja, será necesario 
modularizar la operación. Las técnicas convencionales 
de diseño de componentes se pueden usar para resolver 
esta tarea. 

Las estructuras de datos se diseñan al mismo tiem- 
po que los algoritmos. Ya que las operaciones manipu- 
lan los atributos de una clase, el diseño de estructuras 
de datos, que reflejan mejor los atributos, tendrán un 
fuerte sentido en el diseño algorítmico de las operacio- 


nes correspondientes. 
¿Existe alguna manera 


? de clasificar las operaciones 
(métodos)? 


Aunque existen muchos tipos diferentes de opera- 
ciones, normalmente se pueden dividir en tres grandes 
categorías: (1) operaciones que manipulan los datos de 
alguna manera (por ejemplo, agregando, eliminando, 
reformateando, seleccionando), (2) operaciones que eje- 
cutan cálculos, y (3) operaciones que monitorizan (super- 
visan) al objeto para la ocurrencia de un suceso controlado. 

Por ejemplo, la descripción del proceso HogarSe- 
guro contiene los fragmentos de la oración: «al sensor 
se asigna un número y tipo» y «una contraseña (pass- 
word) maestra programada para habilitar y deshabilitar 
el sistema». Estas dos frases indican varias cosas: 


Que una operación de asignación es importante para 
el objeto Sensor. 

Que una operación programar se aplicará al objeto 
Sistema. 


Que las operaciones habilitar y deshabilitar se apli- 
can a Sistema (finalmente se debe definir el estado 
de sistema usando la notación adecuada en un dic- 
cionario de datos) como: 


[habilitado | 
deshabilitado] 


estado del sistema = 


Cons) 


Una operación se define en gran parte de la misma 
manera en que se refina una función en el diseño 
convencional. Escriba uno descripción del proceso, 
haga un análisis gramatical y aísle nuevas operaciones 
a un nivel de abstracción más bajo. 
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La operaciónprogramar se asigna durante el AOO, 
pero específicamente duranteel diseño del objeto se refi- 
nará un número de operaciones más específicas, que se 
requieren para configurar el sistema. Por ejemplo, des- 
pués de discusionescon el ingeniero del producto, el ana- 
lista, y posiblemente con el departamento de marketing 
(mercadotecnia), el diseñador debe elaborar la descrip- 
ción del proceso original, y escribirlo siguiente para pro- 
gramar (subrayan operaciones potenciales —verbos—): 

Programar habilita al usuario de HogarSeguro para confi- 
gurar el sistema una vez que ha sido instalado.El usuario pue- 
de (1) instalar números de teléfonos; (2) definir tiempos de 
demora para alarmas; (3) construir una tabla de sensores que 
contenga cada 1D de sensor, su tipo y asignación; y (4) cargar 
una contraseña (password) maestra. 


Por consiguiente, el diseñador ha refinado la opera- 
ción simple programar, y se reemplaza con las opera- 


Los mejores diseñadores en cualquier campo tienen 
una habilidad extraña para reconocer patrones que 
caracterizan un problema y los patrones correspon- 
dientes, que pueden combinarse para crear una solu- 
ción. Gamma y sus colegas [GAM95] examinan esto 
cuando afirman que: 


Se encontrarán patrones repetidos de clases y objetos de 
comunicación,en muchos sistemasorientadosa objetos. Estos 
patrones resuelvenproblemas específicosde diseño, y vuelven 
al diseño orientado a objetos más flexible, elegante y extre- 
madamente reutilizable.A yudan a los diseñadores a reutilizar 
diseños exitosos basando nuevos diseños en experiencia pre- 
via. Un diseñador bastante familiarizado con ese tipo de patro- 
nes puede aplicarlos inmediatamente a problemas de diseño, 
sin tener que redescubrirlos. 


Referencia cruzada 


Los potrones existen a nivel tanto de orquitectura 
“coimo de componentes. Paro mayof información, 
'véose el Copfiulo 14. di 


Durante el proceso de DOO, un ingeniero del soft- 
ware debe'observar cada oportunidad en la que puedan 
reutilizar patrones de diseño existentes (cuando cum- 
plen las necesidades del diseño), en vez de crear otros 
nuevos. 


22.4.1. ¿Qué es un patrón de diseño? 


Antes de examinar los patrones con detalle vale la pena 
observar un ejemplo sencillo de un patrón, que se pre- 
senta una y otra vez. Muchas aplicaciones tienen el 
requisito de que solo una instancia de un solo objeto 
debe ser instanciada. Algunos ejemplos de aplicaciones 
y objetos de instancias simples son: 
+. Enun sistema operativo habrá solo un objeto admi- 
nistrador de archivos, que mantiene el registro de 
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ciones: instalar, definir, construiry cargar. Cada una de 
estas nuevas Operaciones se vuelve parte del objeto Sis- 
tema, que tiene conocimiento de las estructuras de datos 
internas, que implementan los atributos de los objetos, 
y que se invoca enviando mensajes con el formato: 


MENSAJE (sistema) —> instalar: ENVÍA teléfono.número; 


que implica que se proporciona al sistema un número 
de teléfono de emergencia, y un mensaje instalar se 
envía al sistema. 

Los verbos denotan acciones u ocurrencias. En el 
contexto de la formalización del diseño del objeto, se 
consideran no sólo verbos, sino frases verbales des- 
criptivas y predicados (por ejemplo, «es igual a»), como 
operaciones potenciales. El análisis gramatical se apli- 
ca recursivamente, hasta que cada operación ha sido 
refinada a su nivel más detallado. 


los archivos del usuario, y proporciona facilidades 
para crear, renombrar y eliminar tales archi: >s, 
Solo existirá una instancia de ese administrac 
archivos. 


En un sistema de control de tráfico aéreo, solo exis- 
tirá una instancia del controlador, que mantiene regis- 
tros de los planes de vuelo y sus posiciones. 


En una aplicación bancaria, solo existirá un contro- 
lador, que mantiene el registro de los cajeros auto- 
máticos utilizados por el banco. 

¿Qué es un patrón de diseño 


4 y por qué se necesitan esos 
patrones? 


La Figura 22.7 muestra la estructura general de este 
patrón, la palabra «static» describe una variable uti- 
lizada para toda la clase. En esta Figura solo se mues- 
tran dos operaciones en la clase Singleton, pero se 
pueden mostrar algunas más dependiendo del con- 
texto. A continuación se muestra un esqueleto en Java 
para el patrón: 

public class Singleton ( 
private static ObjetoSimple instanciatinica = null; 


public static ObjetoSimple instanciaUnica ( ) 


( 
if (instancialinica == null ) 
instanciatinica = new ObjetoSimple ( ); 
return instanciaúinica; 

? 


//Código para constructores, será privado. 


//Código para métodos que implementen la escritu- 
ra de 


/loperaciones dentro de Singleton, que pueden 
incluir 
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//operacionl y operacion2. 


//Código para métodos que implementen operaciones 
de retorno 


//en el objeto Singleton, debe incluir operaciónl 


//operación2 


) 


- Clase Singleton 


«Static» Instancia Única 
Estado Singleton 


«Static» Instancia Única 
. Operación Singleton 1 () 
E: * Operación Singleton 2 () -- 
“Obtener Estado Singleton () 


Return Instancia Única — 


FIGURA 22.7. La estructura general del patrón Singleton. 


El patrón Singleton se implementa por medio de 
una variable de instancia estática, descrita por el atri- 
buto de clase ObjetoSimple. La cual es inicializada 
con null para la instanciación. 

El acceso al objeto Singleton se realiza mediante 
el método instancialrnica. Este comprueba primero 
si ObjetoSimple es igual a null. En caso afirmativo, 
significa entonces que no se ha creado un objeto de 
tipo Singleton, y que el método llamará a un cons- 
tructor privado adecuado para establecer al objeto Sín- 
gleton; en el código anterior esto se realiza cuando el 
argumento del constructor es cero. El constructor uti- 
lizado se declarará como privado, ya que no se desea 
que ningún usuario pueda crear objetos de tipo Sin- 
gleton, excepto si es por medio de instancialrnica, la 
cual se ejecutará, de una vez y por todas, en el momen- 
to de la creación. La clase también contendrá méto- 
dos, que ejecutarán operaciones en un objeto de tipo 
Singleton. 

De este modo, si el patrón Singleton se utilizara en 
un sistema de control de tráfico aéreo, y solo se nece- 
sitara un controlador de aeronaves, entonces el nom- 
bre de la clase anterior debena ser ControladorAéreo, 
y debería tener métodos tales como obtenerContro- 
ladorAéreo, que devuelve la Única instancia de un con- 
trolador de tráfico aéreo. 


224.2. Otro ejemplo de un patrón 


Se ha visto ya un ejemplo de un patrón: Singleton. El 
objetivo de esta sección es describir un patrón más 
complicado, conocido como Memento. 


5 
da 
VE 
El patrón de Memento se usa 
para la recuperación de sistemas. 
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El rol de Memento es el de vigilar el estado O alma- 
cenamiento de recuperación del estado de un sistema, 
cuando se requiera. La Figura 22.8 muestra el dia- 
grama de clase para el patrón. Existen tres elementos 
de este patrón. El primero es ClaseCreadora, el cual 
es una clase que describe objetos cuyo estado debe 
ser almacenado. Existen dos métodos asociados con 
esta clase: fijarValorMemento y construirMemento. 
El primero inicializa su estado, toma un argumento el 
cual es un objeto definido por la clase Memento y 
reestablece su estado con el uso del argumento. El 
segundo crea un objeto de la clase ClaseMemento la 
cual contiene su estado actual. En efecto, fijarMe- 
mento actúa como un recurso de restauración, mien- 
tras que construirMemento lo hace como un recurso 
de almacenamiento. 


Clase Creadora 
: Estado Creador a 


- FijarValorMemento() 
.. ConstruirMemento)) . 


ClaseMemento() 


EstadoMemento() 


ObtenerEstadoMemento() 
FijarEstadoMemento() ' A 


FIGURA 22.8. El patrón Memento. 


La clase ClaseMemento define objetos que man- 
tendrán el estado de un objeto de la clase ClaseCrea- 
dora. Contiene dos métodos obtenerEstadoMemento 
y fijarEstadoMemento. La primera devuelve el esta- 
do que se almacena, mientras que la segunda fija el 
estado a un valor pasado como argumento. El tercer 
elemento del patrón Memento es la clase cliente Care- 
taker, ésta no se muestra en la Figura 22.8. Repre- 
senta una clase que implementa objetos que contienen 
un objeto de la clase ClaseMemento. Tiene un con- 
junto muy limitado de funciones ya que todo lo que 
realiza es almacenar un Memento, no altera ni exa- 
mina los contenidos de un memento. 


22.43. Un ejemplo final de un patrón 


Frecuentemente, existe la necesidad de desarrollar 
un código que lleve a cabo el procesamiento de 
datos accedidos secuencialmente. Este acceso 
secuencial tendrá usualmente la misma forma, y por 
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esto es adecuado para un patrón. El objetivo de esta 
sección es describir tal patrón; ello es debido a 
Grand [GRA99]. Algunos ejemplos de procesa- 
miento secuencial son: 


Un programa de informes debe procesar un archivo 
de datos de empleados, leyendo cada registro y dese- 
chando todos aquellos registros de empleados que 
ganen por encima de una cierta cantidad. 

Un programa editor puede ser consultado por su usua- 
rio, para listar las líneas de texto de un archivo que 
coincidan con un cierto patrón. 

Un programa de análisis de la Web debe leer el 
código fuente de un documento HTML, para descu- 
brir cuantas referencias a otros sitios contiene el docu- 
mento. 


2 ¿Qué hace el Filtro? 


Estas son formas diferentes de procesamiento; de 
cualquier manera, están unidos por el hecho de que 
el procesamiento de datos es de manera secuencial. 
Este procesamiento debe hacerse con base en pala- 
bra por palabra, o con base en registro por registro; 
a pesar de ello, también se aplica al procesamiento 
secuencial, y de aquí que sea una buena oportunidad 
de capturarse en un patrón. Este patrón, conocido 
como Filtro, se muestra en la Figura 22.9. Consta de 
varias clases: 


» FiltroFuente. Esta es la clase que actúa como 
superclase para otras clases concretas, que imple- 
mentan el procesamiento requerido. La clase no 
lleva a cabo la recuperación de los datos que se 
procesarán, pero delega eso al objeto Fuente, cuya 
clase será descrita en la tercera viñeta siguiente. 
El objeto Fuente se pasa por medio del constuc- 
tor ala clase. La clase contiene un método llamado 
obtenerDatos, que recupera los datos que se pro- 
cesarán. 


FiltroFuenteConcreto. Esta es una subclase de la 
clase FiltroFuente. Redefine el método obtenerDa- 
tos, para realizar algunas operaciones extras en los 
datos que han sido leídos, por ejemplo si el patrón 
se utiliza para contar las cadenas de caracteres que 
coinciden con cierto patrón, el código para realizar 
este recuento se coloca aquí. Normalmente este 
método utiliza el método correspondiente obtener- 
Datos, dentro de la super-clase. 


Fuente. Esta clase se asociacon los objetos, que lle- 
van a cabo el proceso de recuperar los datos que se 
procesarán. Esto se logra por medio de un método 
llamado obtenerDatos. 


FuenteConcreta Esta clase es una subclase de 
Fuente e implementa el método obtenerDatos, Su 
función es proporcionar datos a los objetos aso- 
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ciados con las clases FiltroFuenteConcreto, que 
realizarán algún tipo de procesamiento con los 
datos. 


22,4.4. Descripción de un patrón de diseño. 


Las disciplinas maduras de ingeniería hacen un vas- 
to uso de patrones de diseño. La ingeniería del soft- 
ware solo se encuentra en su infancia, con el uso de 
patrones. De cualquier manera, se está procediendo 
rápidamente hacia el comienzo de una taxonomía. 
En general, la descripción de un patrón como parte 
de una taxonomía debe proporcionar [GAM9S5]: 


Nombre del patrón. Por ejemplo Filtro. 


Intención del patrón. Por ejemplo, un patrón debe 
tener la intención de facilitar el mantenimiento, 
pues puede acomodar un número de diferentes tipos 
de objeto. 


Los problemas de diseño que motivan el patrón. 
Por ejemplo, un patrón debe desarrollarse, para que 
un número de transformaciones diferentes de datos 
puedan ser aplicadas a un objeto, muchas de las 
cuales son desconocidas, cuando el patrón es desa- 
rrollado originalmente. 


La solución que resuelve estos problemas. 


¿Cómo se describe un patrón 
de diseño? 


Las clases que se requieren para implementar la 
solución. Por ejemplo, las cuatro clases descritas 
en la Figura 22.9. 


Las responsabilidades y colaboraciones entre las 
clases de solución. Por ejemplo, una clase debe ser 
responsable de la construcción de un objeto, cuyo 
comportamiento varía al tiempo de ejecución. 


Lineamientos que conduzcan a una implementa- 
ción efectiva. Generalmente, existirá un número 
de formas diferentes de programar un patrón; por 
ejemplo, el procesamiento de errores debe ser tra- 
tado de diferentes formas. 


Ejemplos de código fuente. 


Referencias a otros patrones de diseño, O patrones 
que puedan usarse en conjunto con el patrón des- 
crito. 


22.4.5. El futuro de los patrones 


En la actualidad, se ha desarrollado y catalogado un 
número relativamente pequeño de patrones. De cual- 
quier manera, los últimos cinco años han sido testi- 
gos de una tremenda explosión, en términos de 
interés industrial. Los patrones, junto con los com- 
ponentes, ofrecen la esperanza de que la ingeniería 
de software, eventualmente, se parezca a otras dis- 
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ciplinas de ingeniería, con clases volviéndose el aná- 
logo en software de componentes electrónicos, y los 
patrones volviéndose el análogo en software de 
pequeños circuitos hechos de componentes. Antes 
de que esto suceda, existe aún una ingente cantidad 
de trabajo que llevar a cabo al identificar patrones y 
catalogarlos; también, se producirá esta situación, 
cuando el número de patrones existentes se vuelva 
tan grande, que se necesite una forma de indexado 
automática O semiautomática. 


e 
CLA VE 


En la actualidad existe un buen grupo de patrones; 
sh embargo, en los próximos años debería haber 
una verdadera expansión en su uso. 
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FiltroFuente 


«abstracto» ObtenerDatosO 


Las clases FiltroFuente - 
- y FiltroFuenteConcreto 
contendrán ntros métodos: 
pero no se muestran 


. FiltroFuenteConcreto pe 
e al 
==“ ObtenerDatos() 
Y 


«abstracto» ObtenerDatosí) 


A 


FuenteConcreta 
NAAA DEAN 


: ObtenerDatos() 


FIGURA 22.9. El patrón Filtro. 


El objetivo de esta sección es describir, con un grado de 
mayor detalle, el conjunto de notaciones que componen 
el lenguaje UML. Anteriormente, en el Capítulo 21, se 
describen su origen y componentes principales; de hecho, 
muchos de los diagramas presentados en el Capítulo 21 
y en este capítulo han sido expresados en UML. Se ha 
tomado la decisión de utilizar esta notación, porque se ha 
vuelto predominante muy rápidamente en aquellas com- 
pañías que utilizan ideas de ingeniería para desarrollar 
software orientado a objetos. El primer componente que 
se intenta describires el modelo de clases. 


e 
: CLA VE 


UML se está convirtiendo en un estándar de facto 
para el análisis y diseño orientado a objetos. 


22.5.1. El modelo de clases 


Un modelo de clases es una descripción de las clases en 
un sistema y sus relaciones. No describe el comporta- 
miento dinámico del sistema, por ejemplo el compor- 
tamiento de objetos individuales. El primer elemento 
de un diagrama de clases es una descripción de clases 
individuales. La Figura 22.10 muestra como se descri- 
be una clase. La clase describe al cliente de un banco. 

Esta figura es muy simple, ya que solo contiene una 
clase. Consta del nombre de lá clase (Cliente), el nom- 
bre de algunos de sus atributos, por ejemplo el atribu- 
to dirección, que contiene la dirección del cliente, y la 
lista de operaciones; por ejemplo, la operación obte- 
nerNombre recupera el nombre de un cliente. Cada cua- 
dro que representa una clase contiene, por consiguiente, 
una sección que contiene el nombre de la clase, una sec- 
ción que enumera los atributos de los objetos definidos 
por la clase, y una sección que describe las operaciones 
asociadas con tales objetos. 
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Cliente 


Nombre 
Dirección 
Estado 


Obtener cuentas():ConjuntoDeCuentas 
EstablecerNombre(Cadena nombre) 
ObtenerNombre(): Cadena 


No se muestran 


todos tos atributos 
y operaciones 


FIGURA 22.10. Un ejemplo de una clase descrita en UML. 


También en la Figura 22.10 se muestra una ver- 
sión gráfica de los comentarios utilizados en el len- 
guaje de programación. El cuadro, con una esquina 
superior derecha doblada, llama la atención del lec- 
tor a algún aspecto de un diagrama. En el caso de la 
Figura 22.10, se llama la atención del lector, al 
hecho de que muchos de los atributos y operaciones 
asociados con la clase Cliente no se muestran; por 
ejemplo, la colección de cuentas que posee el clien- 
te no se muestran en la sección de atributos de la 
clase. 

La Figura 22.10 es muy simple, en la práctica los 
diagramas de clases en UML mostrarán la relación 
entre clases. Existe un gran número de tipos diferen- 
tes de relaciones, que pueden ser expresadas. La pri- 
mera cosa que tratemos será la generalización. 
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225.2. Generalización 


Esta relación es la que se mantiene entre una clase X y 
otra clase Y, cuando la clase Y es el ejemplo más espe- 
cífico de la clase X. Por ejemplo, una relación de gene- 
ralización existe entre una clase Cuenta, la cual 
representa una cuenta bancaria general, y una cuenta 
corriente, que es un ejemplo específico de una cuenta. 
La Figura 22.11 muestra como se representaría esta rela- 
ción en un diagrama de clases UML. 


No se muestran 


y Operaciones 


CuentaCorriente | Depósito | 


Aquí una clase Cuenta tiene una relación de genera- 
lización con las clases más específicas,como son Cuen- 
taCorriente y Depósito. Esta relación se representapor 
medio de una flecha, que apunta de la clase más espe- 
cífica hacia la clase más general. Una vez más, obser- 
ve que, para propósitos ilustrativos, no se muestra 
ninguna operación o atributo. 


Producto Manufacturado 
EAS 
PERES 


5 y El diamante 
vacío 


representa 
agregación 


FIGURA 22.12. Agregación en UML. 


$ 


ProductoManufacturado 


| Componente 


ComponenteA | ComponenteB | 


FIGURA 22.13. Un diagrama UML de clases mostrando 
generalización y agregación. 
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225.3. Agregación y composición 

La sección anterior describió una relación, que puede 
ser representada en un diagrama de clases UML: gene- 
ralización; las otras relaciones importantes son la agre- 
gación y la composición. Existen dos relaciones que 
establecen que una clase genera objetos, que son parte 
de un objeto definido por otra clase. Por ejemplo, un 
sistema para un fabricante tendrá la necesidad de man- 
tener los datos acerca de los elementos que se están 
fabricando, y de aquellos que se están haciendo. Por 
ejemplo, un ordenador se fabricaría a partir de una exten- 
sa serie de componentes incluyendo su armazón, un dis- 
co duro, un conjunto de tarjetas de memoria, etc. El 
ordenador se construye, a partir de una serie de com- 
ponentes y en un sistema orientado a objetos utilizado 
para dar soporte al proceso de fabricación, existirá una 
relación de agregación entre la clase utilizada para des- 
cribir el producto fabricado y cada uno de sus compo- 
nentes. La Figura 22.12 muestra como se representa esta 
relación, en un diagrama de clases UML. 


Ec ¿Qué es agregación? 


Aquí la línea con un rombo hueco en un extremo 
indica que la clase describe objetos que agregan otros 
objetos, la clase con el rombo unido a ella describe obje- 
tos, que contiene objetos definidos por la otra clase. En 
UML las relaciones normalmente se mezclan. Por ejem- 
plo, la Figura 22.12 habrá un número de componentes, 
que posean una relación de generalización con la clase 
Componente. 


ColecciónCuentas 


FIGURA 22.14. Un diagrama UML de clases mostrando 
composición. 


Esto se muestra en la Figura 22.13, donde Compo- 
nente se asocia con un número de clases más específi- 
cas, que describen los componentes con los que un 
producto fabricado puede ser ensamblado. 


¿Qué es composición? 


Existe una forma especial de agregación, conocida 
como composición. Ésta se usa cuando se tiene una 
situación en la que un objeto contiene un número de 
otros objetos, y cuando el objeto contenedor se elimi- 
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na todas las instancias de los objetos que están conte- 
nidos desaparecen. Por ejemplo, una clase Cliente que 
representa clientes en un banco tendrá una relación de 
composición con las cuentas que el cliente posee; por- 
que si el cliente se elimina, por ejemplo, se mueve a otro 
banco, todas sus cuentas son eliminadas; esta forma de 
relación se indica de manera muy similar a la agrega- 
ción, pero en esta ocasión el rombo está relleno en lugar 
de hueco. Esto se muestra en la Figura 22.14. 


22.54, Asociaciones 

La agregación y la composición son ejemplos específi- 
cos de una relación entre dos clases. Una relación ocu- 
rre entre dos clases cuando existe alguna conexión entre 
ellas, en UML esto se conoce como asociación. Algu- 
nos ejemplos de esto se describen a continuación: 

Una clase Administrador se relaciona con la clase 
Empleado en virtud de que un administrador dirige 
a un número de empleados. 

Una clase Vuelo se asocia con la clase Avión en vir- 
tud de que un avión emprende un vuelo particular. 
Una clase Computadora se relaciona con una clase 
Mensaje en virtud del hecho de que una colección 
de mensajes está esperando el proceso de una com- 
putadora. 

Una clase InformeBancario se relaciona con la clase 
Transacción en virtud de que el informe contiene 
detalles de cada transacción. 


De estas relaciones, sólo la última es de agregación. 
Todas las otras son asociaciones claras. Tales asocia- 
ciones se escriben en UML como una línea recta. Por 
ejemplo, la Figura 22.15 muestra la primera asociación 
de las anteriores. 

Las asociaciones entre clases se documentan en tér- 
minos de la multiplicidad de la asociación y del nom- 
bre de la asociación. A continuación se observará la 
multiplicidad, examinando el ejemplo de la Figura 
22.15. En este ejemplo un simple administrador dirige 
a uno o más empleados, y un solo empleado será diri- 
gido por un solo administrador. Esta asociación se mues- 
tra en la Figura 22.16. 


Administrador 


IIA 
[A A 
Empleado 
AAA 
IC SS 


FIGURA 22.15. Un ejemplo de una relación simple en UML. 


Aquí el 1 que se encuentra al final de la línea de aso- 
ciación indica que un empleado solo es dirigido por un 
administrador; y el 1... que se encuentraen el otro extre- 
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Lara vas en 


mo de la línea determina que un administrador dirige a 
un conjunto de empleados. 

La asociación entre clases puede nombrarse para 
documentar explícitamente la relación. Por ejemplo, la 
Figura 22.17 documenta el hecho de que un adminis- 
trador dirige a un grupo (colección) de empleados. 


Administrador 


1,* 
Empleado 


FIGURA 22.16. Multiplicidad en un diagrama de clases 
en UML. 


Una alternativa para documentar la asociación es 
documentar los papeles (roles) que cada clase juega en 
una asociación. Un ejemplo de esta situación se mues- 
tra en la Figura 22.18. Aquí, la clase Universidad jue- 
ga el rol de hospedar una serie de estudiantes que, a su 
vez, juegan el rol de ser estudiantes miembros de la uni- 
versidad. Normalmente, cuando se documentan las aso- 
ciaciones, se elige el tipo de documentación que se 
utilizará: si la documentación de asociación O la docu- 
mentación de roles de clases que participan en la aso- 
ciación. El realizar ambos, aunque perfectamente válido, 
se considera como un exceso. 


| Administrador | 


1 
Administra 


1..* 
Empleado 
ENS 
— 
FIGURA 22.17. Documentando una Asociación. 


22.5.5. Casos de uso 


Anteriormente, en el Capítulo 21, se examinaron los 
casos de uso. En UML, un caso de uso se documenta 
de manera muy simple, en términos de actores y de un 
caso de uso. Un actor es cualquier agente que interac- 
túa con el sistema que se construye, por ejemplo el pilo- 
to de un avión, un prestatario de libros de una librería 
o el jefe de los empleados en una compañía. Un caso de 
uso documenta alguna acción que el actor ejecuta; por 
ejemplo, el préstamo de un libro, el cambio de direc- 
ción de un avión O la adición de un miembro a un equi- 
po de programación. Un caso de uso simple se muestra 
en la Figura 22.19. Se muestra el usuario de una biblio- 
teca que pide prestado un libro. 
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“Universidad 


Estudiante Miembro 7,* 


FIGURA 22.18. Documentando roles. 


El actor en este caso es el prestatario, que utiliza la 
biblioteca, y el círculo ovalado muestra el caso de uso 
con el mismo nombre debajo. Los casos de uso repre- 
sentan una visión, a un alto nivel funcional, de un sis- 
tema en UML. En general, un sistema grande debe 
contener centenares, si no millares de casos de uso. Un 
fragmento de un grupo de casos de uso relacionados con 
el mismo actor se muestra en la Figura 22.20. 


Prestatario Pedir prestado un libro 


FIGURA 22.19. Un caso de uso sencillo. 


Muestra algunas de las acciones que un administra- 
dor de proyecto debe llevar a cabo, cuando interactúa 
con un sistema de administración de proyectos. 


AT 


o informe de estado 


ES 


Seleccionar plantilla 


o 


NN 


OR 


Terminar proyecto 
Iniciar Proyecto 


FIGURA 22.20. Un conjunto de casos de uso. 


La existencia de un gran número de casos de uso sig- 
nifica que habrá algunos casos de uso que serán utili- 
zados por otros casos de uso. Cuando esto sucede, el 
diagrama de casos de uso UML va a incluir una etiqueta 
conocida como un estereotipo <<uses>>, sobre la fle- 
cha que conduce al caso de uso. Se muestra un ejemplo 
en la Figura 22.21, la cual muestra algunos casos de uso, 
involucrados con un sistema para la administración de 
productos en un almacén (Warehouse). Por ejemplo, el 
administrador del almacén puede hacer una petición a 
nivel de existencias de un producto en particular. Al lle- 
var a cabo estas funciones, el administrador del alma- 
cén genera un número de casos de uso, cada uno de los 
cuales hacen uso de otro caso de uso, que valida el nom- 
bre del producto al que se hace referencia en el caso de 
uso para revisar; por ejemplo, que el administradorhaya 
escrito un nombre de producto válido. 

Aquí, el hecho de que un caso de uso se emplee por 
otros casos, se indica por medio de una flecha con pun- 
ta hueca. 


e 


«uses» 
ultar producto 


Administrador, (uses, 
del almacén. 
] Consultar nivel A Validar 
— de stock producto 
Habrá más casos Sa A 


deuso asociados 


con unadministrador 
del almacén 


Consultar detalles 
de orden 


FIGURA 22.21. Un ejemplo de casos de uso utilizando otro 
caso de uso. 


22.5.6. Colaboraciones 


Durante la ejecución de un sistema orientado a obje- 
tos, los objetos interactuarán con cada uno de los otros. 
Por ejemplo, en un sistema bancario, un objeto Cuen- 
ta puede enviar un mensaje a un objeto transacción 
para crear una transacción que ha ocurrido en una cuen- 
ta, por ejemplo una cuenta de cargo. Este tipo de infor- 
mación es importante para el diseñador de un sistema 
orientado a objetos, durante el proceso de la identifi- 
cación y validación de clases. Por esta razón, UML 
tiene dos notaciones equivalentes para definir las inte- 
racciones. En este libro nos centraremos sólo en uno: 
el diagrama de secuencias; el otro diagrama se cono- 
ce como diagrama de colaboración, y es equivalente 
al diagrama de secuencia; de hecho, son tan similares 
que las herramientas CASE pueden normalmente cre- 
ar un diagrama, a partir de una instancia o de la otra. 
La Figura 22.22 muestra un ejemplo simple de un dia- 
grama de secuencias. 
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En este diagrama existen tres objetos, los cuales 
se involucran en una interacción. El primero es el 
objeto administrador descrito por la clase Emplea- 
do. Esto envía un mensaje actualizarInforme a un 
objeto llamado informeVentas, el cual envía un men- 
saje crearTransacción a un objeto transacción- 
Ventas. 


viejoCliente: 
ClienteBanco 


actualizar Informe ; 


' crearTransacción ; 


; cambiar Detalles » 


FIGURA 22.22. Un diagrama de secuencia sencillo. 


En el diagrama de secuencia existen tres objetos 
involucrados, uno de ellos (administrador)tiene su 
clase específica (Empleado), los otros no. Los con- 
tenidos en los cuadros de un diagrama de secuen- 
cia pueden contener solo el nombre del objeto, el 
nombre de un objeto junto con su clase separado 
por dos puntos, o solo el nombre de una clase pre- 
cedida de dos puntos; en este último caso, el obje- 
to es anónimo. 

La Figura 22.22 también muestra el rol de un actor 
dentro de una colaboración: aquí el actor ClienteBan- 
co y ViejoCliente, interactúa con el administrador del 
objeto Empleado, enviando un mensaje cambiarDe- 
talles. 

La Figura 22.23 muestra otro ejemplo de un diagra- 
ma de secuencias. 


2008 


:ClienteBanco 


* consultaCuenta 


comprobar- 
' CuentaVálida 


' 
' 
' 
; 
' 
1 
: , generarinformeBalance + 
, 
' 
' 
, 


FIGURA 22.23. Otro ejemplo de diagrama de secuencia. 
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Aquí un actor, representado por un objeto anónimo 
definido por la clase InformeBalance, envía un men- 
saje al objeto cuenta, que consulta la cuenta. 

Este objeto comprueba si es una cuenta válida, y lue- 
go envía un mensaje generarInformeBalance a un obje- 
to informeBalance, que contiene los datos requeridos 
por el cliente del banco. 


22.5.7. Diagramas de estado 


Otro componente importante de UML es el diagrama 
de estado. Este muestra los diferentes estados en que un 
objeto se encuentra, y cómo se dan las transiciones de 
cada estado a otros estados. Tal diagrama contiene los 
siguientes componentes: 


Estados: se muestran dentro de cuadros, con esqui- 
nas redondeadas. 


Transiciones entre estados mediante flechas. 


Bl ¿Qué es un diagrama 
de estados? 


Sucesos que provocan las transiciones entre estados: 


Marca de inicio, que muestra el estado inicial, en el 
que un objeto se encuentra cuando se crea. 


Marca de parada (fin), que indica que un objeto ha 
alcanzado el final de su existencia (vida). 


O 


CerrarCuenta 


Cuenta activa 


CrearCuenta 


Transacción 


Transacción Cuenta vacía 


FIGURA 22.24. Ejemplo de un diagrama de estados. 


Un ejemplo de diagrama de estados se muestra en la 
Figura 22.24. 

Aquí se muestra el ciclo de vida de una cuenta ban- 
caria. Cuando la cuenta se crea, se visualiza como una 
cuenta vacía. Hasta que una transacción se lleve a cabo 
(los fondos depositados o retirados de la cuenta se visua- 
lizan como una cuenta activa). El diagrama de estado 
también muestra que, cuando una cuenta se cierra, se 
destruye. 
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El objetivo de esta sección es mostrar el uso de diagra- 
mas UML, descrito en la Sección 22.25, aplicado a un 
sistema real. Este sistema es un sistema de comercio 
electrónico (e-commerce). 


22.6.1. Libros-en-línea 


Libros-en-línea es una compañía creada reciente- 
mente, que es subsidiaria de otra gran compañía mul- 
tinacional de comercio, conocida como Pollday 
Publishing. Los directores de Pollday Publishing se 
decidieron a llevar a cabo un gran crecimiento en ven- 
tas por internet entre sus clientes, y decidieron pre- 
parar a Libros-en-Línea para ello. El concepto que 
Pollday tiene es el de un sitio Web de comercio elec- 
trónico, que tenga catálogos detallados de cada libro 
que manejan, junto con recursos con los que el usua- 
rio del sitio Web puede ordenar libros, utilizando una 
forma incluida en una página Web. A continuación, 
se muestran algunos extractos, tomados del conjun- 
to de requisitos iniciales, detallados por el equipo téc- 
nico de Libros-en-línea: 


1. Libros-en-línea desea desarrollar la capacidad de 
ventas en línea por medio de la Web. EL sitio web 
que implementa esta capacidad debe permitir al 
cliente examinar los detalles del libro, ordenarlo y 
registrar su dirección de correo electrónico para reci- 
bir ofertas especiales con detalles, publicaciones nue- 


vas y revisiones. 


. Cuando un cliente accede al sitio Web, cada uno de 
los recursos antes descritos se despliegan. 


. Siel cliente registra su dirección de correo electró- 
nico, se le preguntarán su informaciónpersonal. Esto 
incluye su nombre, una dirección de correo electró- 
nico, una dirección postal. Un miembro del equipo 
conocido como el administrador de contratos será el 
responsable de enviar información de oferta, etc., a 
los clientes. 


El cliente podrá comprar libros del catálogo en 
línea, examinando las páginas con detalles de los 
libros y seleccionando el libro, que comprará 
mediante algún mecanismo como el de presionar 
un botón. El sistema deberá mantener un carrito de 
compras virtual, en el que los detalles de cada libro 
se almacenan. Conforme el carrito se va llenando 
de libros, se muestra al cliente el precio acumulado 
de todas sus compras. 


. Cuandoel cliente ha terminado de compraren el sitio 
Web, se le pedirá información acerca de qué forma 
de envío se utilizará. Por omisión se mostrará la 
opción de envío por correo estándar, y un servicio 
de envío expreso garantizado para entregar dentro 
de 24 horas. 
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6. El sitio web deberá interactuar con un sistema de 


control de inventario, que también requiere desarro- 
llo. Este sistema de control de inventarios debe mane- 
jar el proceso de recepción de libros de los inventarios 
de las editoriales, retiro de libros cuando se ordenan 
por parte de un cliente, y reordenación de existencia 
de un libro, cuando se encuentra por vaciarse, para 
encarar un problema de suministros, en un tiempo 
de siete días. 


. El control de inventarios por parte del administrador 
será fijado en un tiempo de siete semanas. Él o ella 
tendrán la responsabilidad de mantener las ventas, y 
la disponibilidad de existencias y, cuando las exis- 
tencias de un libro se encuentren bajas, hacer un 
nuevo pedido. Para realizar esto, este sistema de con- 
trol de inventarios debe proporcionar informes de 
ventas y existencias de inventario con regularidad. 


Un Administrador de Marketting intervendrá cada 
ocho semanas. El Jefe de Marketting tendrá la fun- 
ción de determinar los precios a los que los libros 
serán vendidos. Se dará la situación de que un libro 
puede tener un número diferente de precios durante 
su tiempo de vida; por ejemplo, se debe decidir si se 
ofrece con un mayor descuento durante las primeras 
semanas, y luego ajustar el precio a los precios reco- 
mendados por las editoriales. 

La compañía que desarrolló el software para Libros- 
en-línea, primero identificó un número de clases candi- 
datas, que a continuación se detallan: 
RegistroCliente. Detalles de alguien que compra 
libros, o que se registró para recibir correos electró- 
nicos con información. 

Libro. El artículo principal, qué Libros-en-línea 
vende. 

Orden. Una orden que un cliente realiza, para uno 
o más libros. Esta orden debe ser para una simple 
copia de un libro, o para copias de un número de 
libros o incluso múltiples copias de muchos libros. 
Una orden contendrá un número de líneas de orden 
(véase a continuación), y una especificación de envío. 
LíneaDeOrden. Esta es una simple línea de orden. 
Por ejemplo la orden de la copia de un libro. Una 
orden consistirá en una O más líneas de orden. Una 
línea de orden contendrá información acerca de 
qué libro se ordena y la cantidad ordenada (usual- 
mente 1). 

Carrito. Es un contenedor que existe durante la 
exploración del sitio Web, por parte de un cliente que 
realiza una orden. Los contenidos del carrito serán 
líneas de orden. Cuando un cliente complete una 
orden, las líneas de orden del carrito y la informa- 
ción de envío proporcionada por el usuario serán ane- 
xadas a una orden. 
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»  OrdenEspera. Esta es una parte de la orden, la cual 
no puede cumplirse por las existencias del almacén. 
Si el cliente está conforme, esperando por un libro 
que no está en existencia, entonces se realiza una 
orden de espera. Esta orden de espera se satisface, 
cuando las existencias del libro se restauran por 
Libros-en-línea. 

+ Almacén. Esta es una colección de libros que se 
encuentran en existencia. Una orden de libro o de 
colección de libros se manda al almacén y de ahí 
se retiran los libros de sus cajas del almacén, se 
empaquetan y se despachan al cliente. En ese 
momento, se ajustan los detalles de las existen- 
cias. 

» RegistroExistencias. Estos son los datos que des- 
criben los detalles de las existencias de un libro; 
por ejemplo, cuántos hay en existencia, el nivel 
actual cuando se ha hecho una requisición a las edi- 
toriales, y la localización de los libros dentro del 
almacén. 


» NotaEmpaque. Esta es una nota enviada con una 
colección de libros al cliente. La nota de empaque 
contiene información acerca de cuántos libros se 
enviaron y la tarifa de envío aplicada. También puede 
contener detalles de algunos libros, que no pudieron 
ser enviados porque no se encontraban en las exis- 
tencias. 


» TarjetaCrédito. Un cliente pagará por sus libros 
mediante una tarjeta de crédito. El sistema permite 
al cliente pre-registrar su o sus tarjetas, para que 
no tenga que reescribirlas cada vez que haga una 
orden. 


Pedir Libro 


Comprobar pedido 
Cliente 


Encontrar libro 


Borrar tarjeta 
de crédito 


Registrar 
tarjeta de crédito 


FIGURA 22.25. Algunos casos de uso para el actor Cliente. 
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Estas fueron, entonces, las clases identificadas princi- 
palmente. También se identificaronun número de actores: 
+. Cliente. Este es el actor principal: la persona que 

lleva a cabo las acciones, que resultan en los mayo- 

res cambios de estado del sistema. 

.« Administrador de marketting. Es un actor importante 
que ajusta muchos de los parámetros del sistema, 
tales como el precio de los libros. 

. Administrador del control de inventarios. Alguien 
que controla los inventarios en un almacén y toma 
decisiones acerca de las órdenes. 

Existen un gran número de casos de uso asociados 
con estas acciones, muchas de ellas asociados con el 
actor cliente, se muestran en la Figura 22.25. 

La selección de casos de uso asociados con el Cliente, y 
las mostradas en la Figura 22.25 incluyen casos de uso para: 
+. Registro. Aquí el cliente proporciona su nombre y 

su clave. Una vez registrada, pueden examinar el 

catálogo de libros. 

+ Ordenar. Aquí el cliente ordena una o más copias de 
un libro. 

+. Realizar. El cliente completa la orden y ordena al sis- 
tema iniciar el proceso en que la orden se despacha. 

*« Buscar un libro. El cliente busca, en el catálogo en 
línea, un libro específico. 

» Eliminar tarjeta de crédito. Aquí el cliente puede eli- 
minar una O más de las tarjetas de crédito registra- 
das y asociadas con él. 

» Registrar tarjeta de crédito. Aquí el cliente registra 
una O más de sus tarjetas de crédito al sistema. 

Una porción de uno de estos diagramas de clase para 
el sistema, se muestra en la Figura 22,26. Un número 
de roles asociados con el diagrama se ha omitido; regu- 
larmente se incluyen. Algunas de las relaciones entre 
clase, también se omitieron. 

El diagrama muestra muchas de estas clases antes 
descritas. Las únicas clases que se omitieron son: 
OrdenSatisfecha y OrdenEspera. Estas dos clases son 
especializaciones de la clase Orden, que representa una 
orden de libros para un cliente. 


Orden 
Satisfecha 


Registro 


cliente 
AA 


de la tarjeta 


Depósito es 
q. 
Registro 
3 


almacenado 


FIGURA 22.26. Una sección de un diagrama de clases 
para el caso de estudio. 
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Cuando se hace un pedido, algunos de los artículos 
pedidos pudieron no haberse servido, porque los libros 
no estaban en existencia. Cuando esto ocurre, la orden 
se divide en dos: todos los libros que pueden propor- 
cionarse en un objeto OrdenSatisfecha, y aquellos que 
no pudieron encontrarse, seregistran en un objeto Orden- 
Espera. Las relaciones en el diagrama de clases se deta- 
llan a continuación. 


Un almacén se asocia con un número de registros de 
existencias, los cuales detallan los libros almacena- 
dos en el almacén. Un simple almacén se asocia con 
uno O más registros de existencia. 


y un libro se asocia con un soloregistro de existencia. 


Un registro de existencia se asocia con un solo libro, 
U 


na orden puede consistir en un número de líneas 
de orden, y una línea de orden será asociada con una 
ola orden. 


Un cliente registrará su número de tarjeta de crédito 
al sistema, un número de tarjeta de crédito se asocia 
con un solo cliente. 


Un cliente se asocia con un número de órdenes satis- 
fechas, las cuales se realizan sobre un período de 
tiempo. Cada orden satisfecha se asocia con un solo 
cliente. 


Un cliente se asocia con un número de órdenes en 
espera, que actualmente no pueden ser satisfechas. 
Cada orden en espera se asocia con un solo cliente. 


La Figura 22.26 muestra solo algunas de las rela- 
cienes involucradas, por ejemplo, existe una relación 


entre tarjetas de crédito y Órdenes, en virtud de que una 
tarjeta de crédito particular se utiliza para pagar una 
orden. De cualquier manera, se muestra suficiente deta- 
lle para proporcionar una indicación de qué tan com- 
plicado se ve un diagrama de clases UML. 

Un ejemplo de diagrama de secuencias asociado con 
el caso en estudio se muestra en la Figura 22.27. 

Aquí el cliente ordena un libro. Esto resulta en el 
registro de existencias para el libro consultado, y se ajus- 
ta si el libro está en existencia. Si el libro está en exis- 
tencia, un objeto de tipo línea de orden se crea, el cual 
se anexa a una orden, la cual se construye conforme el 
cliente navega por el sitio web de Libros-en-línea. El 
diagrama final (Fig. 22.28) muestra un diagrama de esta- 
do para el objeto Orden. 

Un cliente primero realiza la orden, y el estado del 
objeto Orden se vuelve orden parcial; entonces se da al 
cliente la opción de añadir más libros o de eliminar libros 
de su orden. En cualquier momento de la construcción 
de la orden, el cliente puede cancelar la orden, esto con- 
duce a la terminación. Cuando el cliente indica que se 
ha llegado al fin de la orden, entonces la orden se vuel- 
ve una orden de libros completa. En este punto, el clien- 
te tiene dos opciones: cancelar al orden o especificarel 
tipo de envío que se usará para la orden. Si se seleccio- 
na el tipo de envío, entonces la orden se convierte en 
una orden completa. En esta etapa, el cliente tiene otras 
dos opciones: confirmar la orden, en este caso la orden 
se envía para ser procesada, o cancelar la orden. Ambas 
opciones conducen al punto de salida del diagrama de 
estados. 


La etapa final de desarrollo, dentro del ciclo de vida 
orientada a objetos, es la programación. No es la 
intención de este libro llegar a más detalle acerca de 
este proceso; la programación es analizada como 
importante pero como actividad subsidiaria al análi- 
sis y diseño; pero se proporciona una pequeña intro- 
ducción en el lenguaje de programación Java. La 
sección otras lecturas y fuentes de información al 
final del capítulo detalla un gran número de buenos 
libros sobre el tema. 

El proceso de programación involucra la conversión 
de un diseño orientado a objetos en un código de pro- 
grama. Efectivamente, esto significa que las clases defi- 
nidas en el diseño deben ser convertidas en clases 
expresadas en un lenguaje de programación orientado 
a objetos como Java, C++ 0 Small Talk, Esta sección se 
concentra en Java, que se está volviendo rápidamente 
el lenguaje de programación de facto, para desarrollar 
los modernos sistemas distribuidos. 

Una clase en Java se introduce por medio de la pala- 
bra clave class, dentro del código para la clase; el pro- 
gramador define los atributos y operaciones para la clase. 
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Un ejemplo del código esqueleto de una clase se mues- 
tra a continuación. 


class Cliente ([ 
private String NombreCliente; 
private String DireccionCliente; 
// se definen más atributos aquí 
public String obtenerNombreCliente( ) 
( 
//código para obtenerNombreCliente 
? 


public void modificarDireccionCliente([ String 
direccion) 


( 


//código para modificarDireccionCliente 
? 


//código para las operaciones restantes 


? 


La primera línea de código define que el nombre de 
la clase será Cliente. Inmediatamente a continuación, 
las descripciones de atributos de clase. En el código 
anterior, solo se muestran dos atributos: el nombre del 
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cliente y su dirección; ambos se expresan como cade- 
nas de caracteres. Normalmente, en un sistemareal exis- 
ten muchos más atributos asociados con la clase. La 
descripción del atributo incluye su tipo (String)y su 
visibilidad. En el ejemplo anterior, a los dos atributos 
mostrados se les asigna la visibilidad de privados. Esto 
significa que pueden ser accedidos por cualquier códi- 
go dentro de la clase pero no por alguno fuera de ella; 
por ejemplo, el código que pertenece a otra clase. Esto 
significa que las variables de instancia se encapsulan 
dentro de la clase. Existen otros modificadores de visi- 
bilidad en Java: Se encontrará con otro después, cuan- 
do se describan las operaciones de una clase. 


:RegistroStock Pob 
:Cliente 


+ AñadirAOrden : 
] OrdenLibro | y 
, AceptaciónOrden 


anmasios ' 


” Orden 


FIGURA 22.27. Un diagrama de secuencia para el caso de 
estudio. 


También se han mostrado dos operaciones dentro de 
la clase Cliente. La primera es la operación obtener- 
NombreCliente, que devuelve el nombre del cliente des- 
crito por la clase. 


Orden(libro) 
BorrarOrdenílibro) 
Orden(libro) 
Orden Parcial 
una Completar orden 
rden de libro Seleccionar 
Transporte 


CancelarOrden 


Orden Completa 


(tipo transporte) 


ConfirmarOrden 


OP 


FIGURA 22.28. Un diagrama de estados. 


Cancelarorden 
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La palabra clave String especificaque esta operación 
devolverá una cadena, y la palabra clave public descri- 
be el hecho de que cualquier código de cualquier otra 
clase puede hacer uso de esta operación: public es el 
opuesto de la palabra claveprivate, detallada en el párra- 
fo anterior. 

El código para esta operación se encierra con llaves 
(()p) de operación. 

La operación modificarDirecciónCliente difiere en 
dos cosas de la operación obtenerNombreCliente. En 
primer lugar, le antecede la palabra void; esto indica que 
no hay resultado que regresar de la operación: la ope- 
ración solo lleva a cabo acciones que modifican los atri- 
butos de la clase. En segundo, la operación asociada con 
el argumento dirección, que es una cadena que repre- 
senta la nueva dirección de un cliente, que reemplaza- 
rá a la anterior. 

Esto, entonces, es la forma básica de una clase en 
Java; es muy similar en muchas formas a la estructura 
de clases expresadapara los lenguajes orientados a obje- 
tos, con excepción de SmallTalk. A continuación, se 
muestra el código completo de una clase muy simple. 
La clase representa un contador, que es un dispositivo 
que sirve para registrar el número de veces que una pági- 
na web ha sido accedida por visitantes de un sitio Web. 


class Contador [ 
private int veces; 
public Contador ( int valorInicio ) 
[ 
veces = valorinicio; 
) 
public void ajustaClontador( int valor ) 


( 


veces valor; 


7 
public int obtenerCuenta( ) 


] 
return veces; 


? 


public void incrementaCuenta( ) 
1 
Veceset ; 


? 


La clase denominada Contador tiene un atributo 
veces, que registra el número de veces consultado por 
usuarios. La siguiente operación tiene el mismo nom- 
bre de la clase, y se conoce como constructor. Este es 
un fragmento de código ejecutable, que se ejecuta cuan- 
do el objeto se crea, recibe un argumento entero que es 
el valor inicial del contador. Cuando el usuario de la 
clase desea crear un objeto contador, el código es el 
siguiente: 


Contador cont = new Contador( 0); 


La palabra clave new” llama al constructor para crear 
un objeto contador que tiene un solo atributo veces ini- 
cializado a cero. 
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La operación obtenerCuenta regresa el valor actual del 
contador, la operación ajustaContador ajusta el atributo 
veces a un valor dado por su argumento, y la operación 
incrementaCuenta incrementael atributo veces en uno (la 
operación ++es la operación de incremento en uno). 

La sintaxis de Java para enviar mensajes al objeto es 
la siguiente: 


Objeto.nombreOperación( argumentos ) 


Por ejemplo para incrementar un objeto Contador 
cont el código sería: 


cont. incrementaCuental ); 


La clase anterior es muy simple; de cualquier modo, 
sirve para ilustrar las características estructurales prin- 
cipales de cómo se define una clase. Existen otras com- 
plicaciones, como el hecho de que pueden definirse varios 
niveles de visibilidad; de cualquier modo, esto queda 
fuera del alcance de un libro de ingeniería del software. 

Existen dos maneras de combinar clases: la primera 
es la herencia y la segundaes la agregación. Los lenguajes 
de programación orientada a objetos contienen recursos 
que permiten a ambas ser implementadas fácilmente. 

En Java, la palabra clave extends se utiliza para deri- 
var una clase de una ya existente por medio de la heren- 
cia. Por ejemplo, asúmase que se necesita derivar una 
clase nueva, que se parece mucho a la clase Contador, 
pero que además registra la hora a la que la cuenta se 
incrementó. El esqueleto de la nueva clase, que hereda 
la clase Contador, se muestra a continuación: 

class TiempoContador extends Contador 

// Algunos atributos nuevos 

// Algunas operaciones nuevas. 


) 


La palabra clave extends especifica el hecho de que 
la clase TiempoContador se hereda de la clase Conta- 
dor. El código para la clase se muestra a continuación: 


class TiempoContador extends Contador( 
Time horaAcceso; 
public TiempoContador( int valorInicio ) 
[ 
superí valorinicio ) ; 
horaAcceso = new Time horaAcceso( ) 5 


F 
public void ajustaContador( int valor ) 


í 
super.ajustaContador( int valor ); 
horaAcceso.setNow( ); 

¿ 

public Time obtenHora( ) 

í 
return horaAcceso; 

? 


public void incrementaCuental ) 
[ 
super.incrementaCuentaÍ ) ; 
horaAcceso.setNow( ); 
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Recuérdese que, en la herencia, las operaciones en 
la superclase (en nuestro clase Contador) se heredan por 
la superclase (en nuestro caso TiempoContador), a 
menos que se sobrecarguen. 

La primera operación ajustaContador, sobrecarga al 
método correspondiente en la superclase. Primero ini- 
cializa el atributo veces dentro de la superclase, hacien- 
do una llamada a su constructor (la palabra clave súper 
seutiliza para ello), y luego se construye un nuevo obje- 
to Time. Este objeto se define en cualquier otro lugar, y 
no se debe mostrar el código. La operación ajustaCon- 
tador también sobrecarga la operación correspondiente 
dentro de Contador. El código dentro de la clase prime- 
ro inicializael atributo de la superclase, para que sea igual 
a valor. Luego envía un mensaje setNow al atributohora- 
Acceso, para ajustar su valor a la hora actual, el código 
para la operación sefNow forma parte de la clase Time y 
no se muestra. El método obtenHora es simple: todo lo 
que hace es regresar el valor de horaAcceso. La opera- 
ción incrementaCuenta sobrecargala operación corres- 
pondiente en la clase Contador. Primero incrementa el 
valor de veces, llamando a la operación incrementaCuenta 
dentro de la superclase, luego ajústale valor de horaAc- 
ceso, enviando un mensaje seíNow al objeto. El método 
obtenCuenta, heredado de la clase Contador, no necesi- 
ta ser sobrecargada, ya que todo lo que hace es regresar 
el valor del atributo veces, dentro de la superclase. 

Esto es, como un lenguaje de programación orienta- 
do a objetos implementala herencia. La implementación 
de la agregación es más simple: todo lo que involucra 
es la inclusión de las partes agregadas como atributos de 
clase. Por ejemplo, la clase siguiente Computadora, 
representa a una computadora; forma parte de un siste- 
ma para planificar la fabricación de computadoras. Una 
computadora es agregada desde un monitor, un teclado, 
una unidad de proceso y así sucesivamente. Esto se mues- 
tra en la clase como una serie de atributos. 

class Computer f 

private Monitor mon; 
private KeyBoard kb; 
private Processor proc; 
// demás atributos 


//definición de las operaciones asociadas con 
la computadora. 


) 


Como un ejemplo final de código en Java, se ha 
reproducido mucho del código para un cliente, del 
pequeño caso de estudio mostrado en la Sección 22.6. 
Un cliente es alguien que comprará libros usando inter- 
net. El código para muchos de los métodos se encuen- 
tra a continuación: 


class Cliente 
í 
Ctring nombre, dirección, tipoTarjetaCredito, 
clave, infoSeguridad; 
HistorialCompras Hc; 
OrdenesActuales ordenesA; 


Preferencias pref; 
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Public obtenPrefCliente( ) 
[ 
return pref; 
, 
public Ctring obtenerNombre( ) 


f 
return nombre; 
? 
public Ctring obtenDireccion( ) 
í 


return direccion; 
) 
public Ctring obtenTipoTajetaCredito( ) 
( 
return tipoTarjetaCredi to; 
) 
public Ctring obtenClave( ) 
[ 
return clave; 
z 
public Ctring obtenInfoSeguridad( ) 
( 
return infoSeguridad; 
) 
public void ponNombre( Ctring nom ) 
( 
nombre = nom; 
? 
public void ponDireccion([ Ctring dir ) 
( 
direccion = dir; 
J 
public void ponTipoTarjetaCredito( Ctring ttc ) 
( 
tipoTarjetaCredito = ttc; 
) 
public ponClave( Ctring clv ) 
( 
clave = clv; 
1 
public void ponInfoSeguridad([ Ctring isg ) 
( 
infoSeguridad = 1sg; 
? 
public void ponPreferencias([ Ctring prf ) 
( 
pref = pri; 
1 
public void iniciaHistCompras( ) 
( 
//inicializa el historial de compras con 
el método setClear 
Hc.setClear( ); ' 
? 
public void agregaTransCompra (TransCompra tc ) 
( 
//utilizael método add definido en Histo- 
rialCompras para 
//agregar un libro a la transacción de 
compras al objeto 
/Cliente 
Hc.add(í tc); 
7 
public HistCompras obtenHistCompras( ) 
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( 
return He; 

? 

public void inicOrdenesA( ) 

[ 
//utiliza el método setClear de Ordenes- 
Actuales para 
//inicializar las ordenes actuales 
ordenesA.setClearí ); 

? 


public void agregaOrden/í Orden ord ) 

É 
//Utiliza el método addCurrentOrders de 
OrdenesActuales 
ordenesA.addCurrentOrders( ord ); 


? 

public void borraOrden([ Orden ord ) 

f 
//Utilizael método removeCurrentOrder de 
OrdenesActuales 
OrdenesA.removeCurrentOrder ( Ord ); 

) 

public int numOrdenesActuales( ) 

í 
//Utiliza el método no de la clase Orde- 
nesActuales 
return OrdenesA.no( ); 

) 


public OrdenesActuales obtenOrdenesActuales( ) 


( 


return OrdenesA; 


) 
Muchos de los métodos son muy simples: todo lo que 


hacen es o ajustar u obtener los valores de los atributos 
que se encuentran en la clase Cliente. Estos atributos son: 


nombre. Nombre del cliente. 

dirección. Dirección del cliente. 
tipoTarjetaCrédito. Una cadena que describe el tipo 
de tarjeta de crédito usada por el cliente. 

clave. La cadena usada por el cliente, para acceder 
al sitio de venta de libros. 

infoSeguridad. Esta es una cadena que se utiliza por 
el cliente, para identificarsecon el equipo de servicio 
del sitio, en caso de que se olvide su clave. Por ejem- 
plo, puede contenerel lugar de nacimiento del cliente. 
Ac, Es el historial de los libros que el cliente ha com- 
prado. 

ordenesA. Contiene los detalles de cada orden, que 
se lleva a cabo en ese momento; por ejemplo, una 
orden que no puede ser satisfecha completamente. 
pref. Contiene una lista de preferencias de compra 
para el cliente. Por ejemplo, el hecho de que el cliente 
normalmente compra novelas de terror. 


Existe un grupo de métodos, que pueden llamar a 


métodos definidos en otras clases; por ejemplo, el méto- 
do borraOrden, que elimina una orden de los detalles 
de cliente, y utiliza el método removeCurrentOrder de 
la clase OrdenesA ctuales. 
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El diseño orientado a objetos traduce el modelo de 
AOO del mundo real, a un modelo de implementación 
específica, que puede realizarse en software. El pro- 
ceso de DOO puede describirse como una pirámide 
compuesta por cuatro capas. La capa fundamental se 
centra en el diseño de subsistemas, que implementan 
funciones principales de sistema. La capa de clases 
especifica la arquitectura de objetos global, y lajerar- 
quía de clases requerida para implementar un sistema. 
La capa de mensajes indica cómo debe ser realizada 
la colaboración entre objetos, y la capa de responsa- 
bilidades identifica las operaciones y atributos que 
caracterizan cada clase. 

Al igual que el AOO, existen diferentes métodos de 
DOO. UML es un intento de proporcionar una aproxi- 
mación simple al DOO, que se aplica en los dominios 
de aplicaciones. UML y otros métodos, aproximan el 
proceso de diseño mediante dos niveles de abstracción 
—diseño de subsistemas (arquitectura) y diseño de obje- 
tos individuales —. 


Durante el diseño del sistema, la arquitecturadel sis- 
tema orientado a objetos se desarrolla. Además del desa- 
rrollo de sistemas, de sus interacciones y de su colocación 
dentro de las capas arquitectónicas,el diseño de sistemas 
considera la componente de interacción con el usuario, 
una componente de administraciónde tareas y una com- 
ponente de manejo de datos. Estas componentes de sub- 
sistemas proporcionan la infraestructura de diseño, que 
permite a la aplicación operar efectivamente. El proceso 
de diseño de objetos se centra en la descripción de estruc- 
turas de datos, que usan los atributos de clase, los algo- 
ritmos que usan las operaciones y los mensajes que 
permiten colaboraciones entre objetos relacionados. 

Los patrones de diseño permiten al diseñador crear 
la arquitectura de diseño integrando componentes reu- 
sables. La programación OO extiende el modelo de dise- 
ño a un dominio de ejecución. Un lenguaje de 
programación OO se usa para traducir las clases, atri- 
butos, operaciones y mensajes, de manera que puedan 
ejecutarse por la máquina. 
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21.1. La pirámide de diseño para el DOO difiere, de alguna 
manera, de la descrita para el diseño del software conven- 
cional (Capítulo 13). Vea las diferencias y semejanzas de 
ellas dos. 


21.2. ¿Cómo difieren el DOO y el estructurado? ¿Qué aspec- 
tos de estos dos métodos de diseño son los mismos? 


21.3. Revise los cinco criterios para la modularidad eficaz exa- 
minados en la Sección 22.1.2. Usando el enfoque de diseño 
descrito posteriormente en el capítulo, demuestre cómo se 
logran estos cinco criterios. 


21.4. Seleccione uno de los métodos de DOO presentados en 
la Sección 22.1.3, y prepare un tutorial de una hora para su 
clase. Asegúrese de mostrar todas las convenciones gráficas 
de modelado que sugiere el autor. 


21.5. Seleccione un método de DOGO no presentado en la Sec- 
ción 22.1.3, (por ejemplo, HOOD), y prepare un tutorial de 
una hora para su clase. Asegúrese de mostrar todas las con- 
venciones gráficas de modelado que sugiere el autor. 


21.6. Analice cómo los casos de uso pueden servir como una 
fuente importante de información para el diseño. 


21.7. Investigue un entorno de desarrolloIGU, y muestre cómo 
el componente de interacción hombre-máquina seimplemen- 
taen el mundo real. ¿Qué patrones de diseño se ofrecen y cómo 
se usan? 


21.8. La gestión de tareas en sistemas OO puede ser muy com- 
pleja. Realice alguna investigación sobre métodos de DOO, 
para sistemas en tiempo real (por ejemplo, [BIH92] o 
[DOU99]) y determine cómo la gestión de tareas se realiza 
dentro de este contexto. 


21.9. Examine cómo el componente de manejo de datos se 
implementa en un entorno de desarrollo OO típico. 


21.10. Escriba un artículo de dos o tres página sobre bases de 
datos orientadas a objetos, y analice cómo pueden usarse, para 
desarrollarel componente de gestión de datos. 


21.11. ¿Cómo reconoce un diseñador las tareas que deben ser 
recurrentes? 


Además de las muchas referencias de este capítulo, los libros 
de Gossain y Graham (Objectmodelling and Design Strate- 
giles, SIGS Books, 1998), Meyer (Object-Oriented Design 
Through Heuristics, Addison-Wesley, 1996), y Walden, Jean- 
Marc Nerson (Seamless Object-Oriented Software Architec- 
ture: Analisis and Design of Reliable Systems, Prentice-Hall, 
1995)cubren con bastante detalle el DOO. Fowler (Refacto- 
ring: improving the Design of Existing Code, Addison-Wes- 
ley, 1999) dirige el uso de técnicas orientadas a objetos para 
rediseñar y reconstruir programas antiguos con el fin de mejo- 
rar su calidad de diseño. 

Muchos libros de diseño orientado a objetos publicados 
recientemente enfatizan UML. El lector seriamente interesa- 
do en aplicar UML a su trabajo debe adquirir [BOO99], 
[RUM99] y [JAC99]. Además, muchos de los libros referi- 
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21.12. Aplique el enfoque del DOO examinado anteriormen- 
te en este capítulo, para diseccionar el diseño del sistema 
HogarSeguro. Defina todos los subsistemasrelevantes, y desa- 
rrolle el diseño de objetos para las clases importantes. 


21.13. Aplique el enfoque del DOO examinado en este capí- 
tulo al sistema SSRB descrito en el problema 12.13. 


21.14. Describa un juego de vídeo y aplique el enfoque del 
DOO examinado en este capítulo, para representar su diseño. 


21.15. Usted es responsable del desarrollo de un sistema de 
correo electrónico a implementarse sobre una red de PC. El 
sistema de e-mail permitirá alos usuarios escribir cartas diri- 
gidas a otro usuario o a una lista de direcciones específica. 
Las cartas pueden ser enviadas, copiadas, almacenadas, etc. 
El sistema de correo electrónico hará uso de las capacidades 
de procesamiento de texto existentes para escribir las cartas. 
Usando esta descripción como punto de partida, derive un 
conjunto de requisitos, y aplique las técnicas de DOO, para 
crear un diseño de alto nivel, para el sistema de correo elec- 
trónico. 


21.16. Una nación ubicada en una pequeña isla ha decidido 
construir un sistema de control de tráfico aéreo (CTA) para su 
único aeropuerto. El sistema se especifica como sigue: 


Todos los aviones que aterrizan en el aeropuerto deben 
tener un transmisor que transmita el tipo de avión y los 
datos del vuelo en un paquete, con formato de alta densi- 
dad, a la estación de CTA de tierra. La estación de CTA de 
tierra puede interrogar a un avión, para solicitar informa- 
ción específica y almacenarla en una base de datos de avio- 
nes. Se crea un monitor de gráficos por ordenador, a partir 
de la información almacenada, y se la muestra a un con- 
trolador de tráfico. El monitor se actualiza cada 10 segun- 
dos. Toda la información es analizada, para determinar si 
existen «situaciones peligrosas». El controlador de tráfico 
aéreo puede interrogar la base de datos, para buscar infor- 
mación específica acerca de cualquier avión que se mues- 
tre en pantalla. 


Usando el DOO, cree un diseño para el sistema de CTA. 
No intente implementarlo. 


dos en la sección otras lecturas yfuentes de información del 
Capítulo 21 también se centran en el diseño con un nivel de 
detalle considerable. 

El uso de patrones de diseño para el desarrollo de soft- 
ware orientado a objetos tiene importantes implicaciones 
para la ingeniería del software basada en componentes, la 
reutilización en general y la calidad global de los sistemas 
resultantes. Además de [BUS96] y [GAM95], muchos libros 
recientes dedican sus páginas al mismo tema, como los 
siguientes: 

Ambler, S.W., Process Patterns: Building Large-Scale 
Systems Using Object Technology, Cambridge University 
Press, 1999. 

Coplien, J.O., D.C. Schmidt, Pattern Languages of Pro- 
gram Design, Addison-Wesley, 1995. 
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Fowler, M., Analysis Patterns: Reusable Object Models, 
Addison-Wesley, 1996. 

Grand, M., Patterns in Java, vol. 1, John Wiley, 1998. 

Langr, J., Essential Java Style: Patterns for Implementa- 
tion, Prentice-Hall, 1999. 

Larman, C., Applying Un! and Patterns: An Introduction 


to Object-OrientedAnalysis and Design, Prentice-Hall, 1997. 


Martin, R.C., etal., Pattern Languages of Program Design 
3, Addison-Wesley, 1997. 
Rising, L., y J. Coplien (eds.), The Patterns Handbook: 


Techniques, Strategies, and Applications, SIGS Books, 1998. 


Pree, W., Design Patterns £or Object-Oriented Software 
Development, Addison-Wesley, 1995. 

Preiss, B., Data Structures and Algorithms with Object- 
Oriented Design Patterns inJava, John Wiley, 1999. 

Vlissides, J., Pattem Hatching: Design Patterns Applied, 
Addison-Wesley, 1998. 

Vlissides, J.M., J.O. Coplien y N. Kerth, Pattern Lan- 
guages of Program Design 2, Addison-Wesley, 1996. 

Cientos de libros de programación orientada a objetos 
(POO) han sido publicados. Una muestra de libros específi- 
cos en lenguajes de POO: 

C++: Cohoon, J.P., C++ Program Design: An Introduc- 
tion to Programming and Object- Oriented Design,McGraw- 
Hill, 1998. 

Barclay, K., y J. Savage, Object-Oriented Design With 
C++, Prentice-Hall, 1997. 
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Eiffel: Thomas, P., y R. Weedon, Object-Oriented Pro- 
gramming in Etffel, Addison-Wesley, 1997. 

Jezequel, J.M., Ohject-Oriented Software Engineering 
With Eiffel, Addison-Wesley, 1996. 

Java: Coad, P., M. Mayfield y J, Kem, Java Design: Buil- 
ding Better Apps and Applets, 2.? ed., Prentice-Hall, 1998. 

Lewis, J., y W. Loftus, Java Software Solutions: Founda- 
tions of Program, Addison-Wesley, 1997. 

Smalltalk: Sharp, A., Smalltalk by Example: The Develo- 
per's Guide, McGraw-Hill, 1997. 

LaLonde, W.R., y J.R. Pugh, Programming in Smalltalk, 
Prentice-Hall, 1995. 

Los libros que cubren temas de DOO, mediante el uso de 
dos o más lenguajes de programación, proporcionan una idea 
y comparación de las capacidades de los lenguajes. Algunos 
títulos son: 

Drake, C., Ohject-Oriented Programming With C++ and 
Smalltalk, Prentice Hall, 1998. 

Joyner, L, Objects Unencapsulated: Java, Eiffel and C++, 
Prentice Hall, 1999. 

Zeigler, B.P., Objects and Systems: Principled Design With 
Implementations in C++ and Java, Springer Verlag, 1997. 

Una amplia variedad de fuentes de información sobre dise- 
ño orientado a objetos, así como temas relacionados, están 
disponibles en internet. Una lista actualizada de referencias 
a sitios (páginas) web, que pueden ser relevantes al DOO, 
pueden encontrarse en http://www.pressman5.com 
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PRUEBAS ORIENTADAS 
A OBJETOS 


L objetivo de las pruebas, expresado de forma sencilla, es encontrar el mayor número 
posible de errores con una cantidad razonable de esfuerzo, aplicado sobre un lapso de 
tiempo realista. A pesar de que este objetivo fundamental permanece inalterado para el 
software orientado a objetos, la naturaleza de los programas OO cambian las estrategias y las 
tácticas de prueba. 
Puede argumentarse que, conforme el AOO y el DOO maduran, una mayor reutilización de 
patrones de diseño mitigarán la necesidad de pruebas intensivas en los sistemas OO. La verdad 
es justo lo contrario. Binder [BIN94b|] lo analiza, cuando afirma que: 


Cada reutilización es un nuevo contexto de uso y es prudente repetir las pruebas. Parece probable que 
se necesitarán menos pruebas para obtener una alta fiabilidad en sistemas orientados a objetos. 


La prueba de los sistemas OO presentan un nuevo conjunto de retos al ingeniero del soft- 
ware. La definición de pruebas debe ser ampliada para incluir técnicas que descubran errores 
(revisiones técnicas formales), aplicadas para los modelos de ADO y DOO. La integridad, com- 
pleción y consistencia de las representaciones OO deben ser evaluadas conforme se constru- 
yen. Las pruebas de unidad pierden mucho de su significado, y las estrategias de integración 
cambian de modo significativo. En resumen, las estrategias y tácticas de prueba deben tomar- 
se en cuenta para las características propias del software OO. 


VISTAZO RÁPIDO 


¿Qué es? La arquitectura de software la frustración asociada con un produc- : basado en uso: y pruebas de agrupa- 


orientado a objetos se manifiesta en 
una serie de subsistemas organizados 
por capas, que encapsulan clases que 
colaboran entre sí. Cada uno de estos 
elementos del sistema (subsistemas y 
clases), realizan funciones que ayudan 
aalcanzar requerimientos del sistema. 
Es necesario probar un sistema 00, en 
una variedad de niveles diferentes, en 
un esfuerzo para descubrir errores, que 
deben ocurrir cuando las clases cola- 
boran con otras entre sí, y los subsis- 
temas se comunican por medio de las 
capas arquitectónicas. 


:. ¿Quién lo hase? Las pruebas orienta- 


das a objetos serealizan por ingenie- 
ros de software y especialistas en 
pruebas. 


- ¿Por qué es importante? Se debe eje- 


cutar el programa antes de que llegue 
al cliente, con la intención específica 
de descubrir todos los errores, de 
manera que el cliente no experimente 


to de baja calidad. Conel propósito de 
encontrar el mayor número posible de 
errores, las pruebas deben conducirse 


sistemáticamente. y los casosde prue- 


ba deben ser designados mediante téc- 
nicas disciplinadas. 


¿Cuéles son los paros? Las pruebas 
00 son estratégicamente similares a. 


las pruebas de sistemasconvenciona- 
les. pero tácticamente diferentes. Ya 
que los modelos de análisis y diseño 
00 son similares en estructura y con- 


tenido al programa 00, las «pruebas» . 
comienzan con la revisión de estos .. 
modelos. Una vez que se ha generado 


el código, las pruebas VO comienzan 
«en lo pequeño. con las pruebas de 


clases. Existen pruebas disefíadas - 


para probar las operaciones de las cla- 
ses y examinar si los errores existen 
cuando una clase colabora con otras. 
Así como las clases se integran para 
formar un subsistema basado en hilos, 


407 


miento; junto con los enfoques basados 


en fallos, se aplican para probar 


“«.exhaustiramente las clases colabora» 
:¿¿doras, Por último, los casos de usg 


(desarrollados como parte del modelo 


«de análisis OC) se Usanpara descubrir 


errores en el sc ftware a nivel de vali- 
dación, 


"¿Cuál es el producto obtenido? Se 


diseñan y documer tan un conjunto de 
casos de prueba, diseñados para pro- 
bar clases, sus colaboraciones y com” 
portamien 0s; sedefinen los resultados 


.€sperados y se registran los resultas 
“ dos reales 
¿Cómo pued o estarseguro de quelo 


he hecho correctamente? Cuando 


comienzan las pruebas, secambia sy 
punto de ista. ¡Intenta «romper» el 


software! Diseñar los casos de prueba 
de una forma disciplinada y revisar los 
casos de prueba que secrean con meti- 
culosidad. 


www.elsolucionario.net 


INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRACTICO 


La construcción del software orientado a objetos 
comienza con la creación de los modelos de análisis 
y diseño (Capítulos 21 y 22). Debido a la naturaleza 
evolutiva del paradigma de ingeniería de software OO, 
estos modelos comienzan como representaciones, rela- 
tivamente informales, de los requisitos del sistema, y 
evolucionan en modelos detallados de clases, cone- 
xiones y relaciones de clases, el diseño del sistema y 
el diseño de objetos (incorporando un modelo de 
conectividad de objetos por medio de mensajes). En 
cada etapa, los modelos pueden probarse, en un inten- 
to de descubrir errores, antes de su propagación a la 
siguiente iteración. 


Debido a su copocidad pora detector y corregir 
tos en productos de trabojo anteriores, 
visiones técnicas son por lo menos 

tan importontes, en el control de los costes 

y la plonificación, como los pruebas. 

"Steve McConnell 


Puede argumentarse que la revisión de los mode- 
los de análisis y diseño VO son especialmente útiles, 
ya que las mismas estructuras semánticas (por ejem- 
plo, clases, atributos, operaciones, mensajes), apare- 
cen en los niveles de análisis, diseño y codificación. 
Por consiguiente, un problema en la definición de los 
atributos de las clases que se descubren durante el 
análisis evitará efectos laterales que pueden ocurrir 
si el problema no se descubriera hasta el diseño o 
implementación (o incluso la siguiente iteración del 
análisis). 

Por ejemplo, considérese una clase en la que el núme- 
ro de atributos se definen durante la primera iteración 
del AOO. Un atributo externo (extraño), se agrega a la 
clase (debido al malentendido del dominio de proble- 
ma). Se especifican dos operaciones para manipular el 
atributo. Se realiza una revisión y un experto en el domi- 
nio señala el error. Eliminando el atributo irrelevante 
en esta etapa, los problemas y esfuerzos innecesarios se 
evitan durante el análisis: 


1. Pueden haberse generado subclases especiales para 
adoptar (alojar) el atributo innecesario o excepcio- 
nes a él. El trabajo involucrado en la creación de sub- 
clases no necesarias se ha evitado. 


. Una mala interpretación de la definición de la clase 
puede conducir a relaciones de clases incorrectas o 
irrelevantes. 
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3. El comportamiento del sistema o sus clases pueden 
caracterizarse inadecuadamente, para alojar el atri- 
buto irrelevante. 


Si el error no se descubre durante el análisis y se pro- 
paga más allá, los siguientes problemas pueden ocurrir 
(y tendrán que evitarse con una nueva revisión) duran- 
te el diseño: 


1, La localización impropia de la clase a un subsistema 
y/o tareas puede ocurrir durante el diseño del sis- 
tema. 


. El trabajo del diseño innecesario tendrá que serrecu- 
perado, para crear el diseño procedimental, para las 
Operaciones que afecten al atributo innecesario. 


. El modelo de mensajes (mensajería) será incorrecto 
(debido a que deben diseñarse mensajes para las ope- 
raciones innecesarias). 


Si el error permanece sin detectarse durante el diseño 
y pasa a la actividad de codificación, se gastará un 
esfuerzo considerable para generar el código que imple- 
menta un atributo innecesario, dos operaciones innece- 
sarias, mensajes que controlan comunicaciones entre 
objetos, y muchos otros aspectos relacionados. Además, 
la prueba de la clase absorberá más tiempo del necesa- 
ri0. Una vez que se encuentra el problema en su totali- 
dad, debe llevarse a cabo la modificación del sistema, 
teniendo siempre presentes los posibles efectos colate- 
rales producidos por el cambio. 


Conse) 


Existe un viejo dicho que dice «cortar por lo sano». 
Sipierde tiempo revisando los modelos de ADO 
y DOO, después lo ganará. 


Durante las etapas finales de su desarrollo, los mode- 
los de AOO y de DOO proporcionan información subs- 
tancial acerca de la estructura y comportamiento del 
sistema. Por esta razón, estos modelos deben estar some- 
tidos a una revisión rigurosa, antes de la generación de 
código. 

Todos los modelos orientados a objetos deben ser 
probados (en este contexto, el término «prueba» se uti- 
liza para incorporar revisiones técnicas formales), para 
asegurar la exactitud, compleción y consistencia 
[MGR094], dentro del contexto de la sintaxis, semánti- 
ca y pragmática del modelo [LIN94]. 
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Los modelos de análisis y diseño no pueden probarse en 
el sentido convencional, ya que no pueden ejecutarse. Sin 
embargo, se pueden utilizar las revisiones técnicas for- 
males (Capítulo 8) para examinar la exactitud y consis- 
tencia de ambos modelos de análisis y diseño. 


23.2.1. Exactitud de los modelos de ADO y DOO 


La notación y sintaxis que se utiliza para representar los 
modelos de análisis y diseño se corresponderá con el 
método específico de análisis y diseño, elegido para el 
proyecto. Por consiguiente, la exactitud sintáctica se 
juzga en el uso apropiado de la simbología; cada mode- 
lo se revisa para asegurarse de que se han mantenido 
las convenciones propias del modelado. 

Durante el análisis y diseño, la exactitud semántica 
debejuzgarse basada en la conformidad del modelo con 
el dominio del problema en el mundo real. Si el mode- 
lo refleja con exactitud el mundo real (al nivel de deta- 
lle apropiado a la etapa de desarrollo en la que se revisa 
el modelo), entonces es semánticamente correcto. Para 
determinar si el modelo en realidad refleja el mundo real, 
debe presentarse a expertos en el dominio del problema, 
quienes examinarán las definiciones de las clases y sus 
jerarquías, para detectar omisiones o ambigijedades. Las 
relaciones entre clases (conexiones de instancia) se eva- 
lúan para determinar si reflejan con exactitud conexio- 
nes del mundo real". 


232.2. Consistencia de los modelos de A0O 
y DOO 


La consistencia de los modelos de ADO y DOO debe 
juzgarse «considerando las relaciones entre entidades 
dentro del modelo. Un modelo inconsistentetiene repre- 
sentaciones en una parte, que no se reflejan correcta- 
mente en otras partes del modelo» [MGR94]. 

Para evaluar la consistencia, se debe examinar cada 
clase y sus conexiones a otras clases. Un modelo clase- 
responsabilidad-colaboración (CRC), y un diagrama 
objeto-relación pueden utilizarse para facilitar esta acti- 
vidad. Como se comentó en el Capítulo 21, el modelo 
CRC se compone de una tarjeta índice CRC. Cada tar- 
jeta CRC muestra el nombre de la clase, sus responsa- 
bilidades (operaciones) y sus colaboradores (otras clases 
a las que se envían mensajes y de las cuales depende 
para el cumplimiento de sus responsabilidades). Las 
colaboraciones implican una serie de relaciones (por 
ejemplo, conexiones), entre clases del sistema OO. El 
modelo objeto-relaciónproporciona una representación 


l Los casos de uso poseen un valor incalculable, en el seguimiento 
de los modelos de análisis y diseño, frente a los escenarios del mundo 
real para el sistema OO. 
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gráfica de las conexiones entre clases. Toda esta infor- 
mación se puede obtener del modelo de AOO (Capítu- 
lo 21). 


EE 


Modelos de ADO 


Para evaluar el modelo de clases, se recomiendan los 
siguientes pasos [MGR94]: 


1. Revisar el modelo CRC y el modelo objeto-relación. 

«Realizar un control cruzado, para asegurarse de que 

todas las colaboraciones implicadas en el modelo de 
AOO hayan sido representadas adecuadamente. 


¿Qué pasos deben seguirse 
"para revisar el modelo 
de clases? 


. Inspeccionar la descripción de cada tarjeta CRC, 

para determinar si alguna responsabilidad delegada 
esparte de la definición del colaborador. Por ejem- 
plo, considérese una clase definida para un sistema 
de control de punto de venta, llamada venta a cré- 
dito. Esta clase tiene una tarjeta CRC, que se ilustra 
en la Figura 23.1. 
Para esta colección de clases y colaboraciones, se 
pregunta si alguna responsabilidad (por ejemplo, leer 
la tarjeta de crédito)se cumple si se delega al cola- 
borador nombrado (Tarjeta de crédito). Esto signi- 
fica que la clase Tarjeta de crédito posee una 
operación para ser leída. En este caso, la respuesta 
es «Sí». El objeto-relación se recorre,. para asegu- 
rarse de que todas las conexiones son válidas. 


Referencia cruzada 


Sugerencias adicionalespara conducir una revisión 
del modelo CRC se presentan en el Capítulo 21. 


pd 


Invertir la conexión para asegurarse de que cada cola- 
borador que solicita un servicio recibe las peticiones 
de una fuente razonable. Por ejemplo, si la clase Tar- 

jeta de crédito recibe una petición de cantidad de 
compra de la clase Venta a crédito, existirá un pro- 
blema. Tarjeta de crédito no reconoce la cantidad de 
compra. 
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Nombre de la clase: venta a crédito 


Tipo de la clase: evento de transacción nl 


Características de la clase: intangible, atómica, secuencial, [HE 
permanente, protegida 


Responsabilidades: | Colaboradores: 
Leertarjeta de crédito | Tarjeta de crédito 


Obtener autorización 


Autorización de crédito 


Enviar por correo 
cantidad de compra 


Etiqueta de producto 


Vendedor 


CECI ET 


FIGURA 23.1. Un ejemplo de tarjeta índice CRC usada para 
revisión. 


4. Utilizando las conexiones invertidas, ya examina- 
das en elpaso 3,determinarsi otras clases se requie- 
ren y si las responsabilidades se han repartido 
adecuadamente entre las clases. 


. Determine si las responsabilidades muy solicita- 
das, deben combinarse en una sola responsabili- 
dad. Por ejemplo, leer tarjeta de crédito y obtener 
autorización ocurren en cada situación. Por consi- 
guiente, se pueden combinar en la responsabilidad 
validar petición de crédito, que incorpora obtener 
el número de tarjeta de crédito, y conseguir la auto- 
rización. 

6. Se aplican iterativamente lospasos 1 a 3 para cada 

clase, y durante cada evolución del modelo de 


AOO. 


Una vez que se crea el modelo de DOO (Capítulo 22), 
deben llevarse a cabo también las revisiones del diseño 
del sistema y del diseño de objetos. El diseño del siste- 
ma describe el producto arquitectónico global, los sub- 
sistemas que componen el producto, la manera en que 
los subsistemas se asignan a los procesadores, la asig- 
nación de clases a subsistemas y el diseño de la interfaz 
de usuario. El diseño de objetos presenta los detalles de 
cada clase, y las actividades de mensajería necesarias 
para implementar las colaboraciones entre clases. 


El 


Modelos de DOO 


El diseño de sistema se revisa examinando el mode- 
lo objeto-comportamientodesarrollado durante el AOO, 
y la correspondencia necesaria del comportamiento del 
sistema, frente a los subsistemas diseñados para lograr 
este comportamiento. 

La concurrencia y asignación de tareas también se 
revisan dentro del contexto del comportamiento del sis- 
tema. Los estados de comportamiento del sistema se eva- 
lúan para determinar cuáles existen concurrentemente. 
Los escenarios o situaciones de los casos de uso se uti- 
lizan para validar el diseño de la interfaz de usuario. 

El modelado de objetos debe probarse frente a la red 
objeto-relación, para asegurarse de que todos los obje- 
tos de diseño contienenlos atributos y operaciones nece- 
sarias y para implementar las colaboraciones que se 
definieron para cada tarjeta CRC. Además, la especifi- 
cación detallada de las operaciones (por ejemplo, los 
algoritmos que implementan a las operaciones), se revi- 
san usando técnicas de inspección convencionales. 


22,3 ESTRATEGIAS DE PRUEBAS OBIENTADAS A OBIETOS dl 


La estrategiaclásica para la prueba de software de orde- 
nador, comienza con «probar lo pequeño» y funciona 
hacia fuera haciendo «probar lo grande». Siguiendo la 
jerga de la prueba de software (Capítulo 18), se comien- 
za con las pruebas de unidad, después se progresa hacia 
las pruebas de integración y se culmina con las pruebas 
de validación del sistema. En aplicaciones convencio- 
nales, las pruebas de unidad se centran en las unidades 
de programa compilables más pequeñas —+el subpro- 
grama (por ejemplo, módulo, subrutina, procedimiento, 
componente) —. Una vez que cada una de estas unida- 
des han sido probadas individualmente, se integran en 
una estructura de programa, mientras que se ejecutan 
una serie de pruebas de regresión para descubrir errores, 
debidos a las interfaces entre los módulos y los efectos 
colaterales producidos por añadir nuevas unidades. Por 
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último, el sistema se comprueba como un todo para ase- 
gurarse de que se descubren los errores en requisitos. 


or no es el que encuentra 
de los errores...; el mejor 

la mayoría de ellos. 
de 


23.3.1. Las pruebas de unidad en el contexto 
de la OO 


Cuando se considera el software orientado a objetos, el 
concepto de unidad cambia. La encapsulación conduce 
a la definición de clases y objetos. Esto significa que 
cada clase y cada instancia de una clase (objeto), envuel- 
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ven atributos (datos) y operaciones (también conoci- 
dos como métodos o servicios), que manipulan estos 
datos. En vez de probar un módulo individual, la uni- 
dad más pequeña comprobable es la clase u objeto 
encapsulado. Ya que una clase puede contener un núme- 
ro de operaciones diferentes, y una operación particu- 
lar debe existir como parte de un número de clases 
diferentes, el significado de la unidad de prueba cam- 
bia drásticamente. 

No se puede probar más de una operación a la vez 
(la visión convencional de la unidad de prueba), pero sí 
como parte de una clase. Para ilustrar esto, considére- 
se una jerarquía.de clases, en la cual la operación X se 
define para la superclase y se hereda por algunas sub- 
clases. Cada subclase utiliza la operación X, pero se 
aplica en el contexto de los atributos y operaciones pri- 
vadas que han sido definidas para la subclase. Ya que el 
contexto en el que la operación X se utiliza varía de 
manera sutil, es necesario para probar la operación X 
en el contexto de estas subclases. Esto significa que pro- 
bar la operación X en vacío (la aproximación de la prue- 
ba de unidades tradicionales) es inefectiva en el contexto 
orientado a objetos. 


KO» 
LAVE 


la prueba de software 00 es equivalente al módulo 
de pruebas unitariaspara el software convencional. 
No es recomendable comprobar operaciones por separado. 


La prueba de clases para el software OO es el equiva- 
lente de las pruebas de unidad para el software conven- 
cional*.A diferencia de las pruebas de unidad del software 
convencional que tienden a centrarse en el detalle algo- 
ntmico de un módulo y de los datos que fluyen a través 
de la interfaz del módulo, la prueba de clases para el soft- 
ware OO se conduce mediante las operaciones encapsu- 
ladas por la clase y el comportamiento de la clase. 


23.3.2, Las pruebas de integración 
en el contexto OO 


Ya que el software orientado a objetos no tiene una 
estructura de control jerárquico, las estrategias con- 
vencionales de integración descendente (top-down) y 
ascendente (bottom-up) tienen muy poco significado. 
En suma, la integración de operaciones una por una en 
una clase (la aproximación de la integración incremen- 
tal convencional), a menudo es imposible por la «inte- 
racción directa e indirecta de los componentes que 
conforman la clase» [BER93]. 

Existen dos estrategias diferentes para las pruebas 
de integración de los sistemas OO [BIN94a]. El prime- 


2 Los métodos de diseño para pruebas de caso, para las clases OO, 
se discuten de las Secciones 23.4 a 23.6. 
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ro, las pruebas basadas en hilos, integran el conjunto 
de clases requeridas, para responder una entrada o suce- 
so al sistema. Cada hilo se integra y prueba individual- 
mente. Las pruebas de regresión se aplican para asegurar 
que no ocurran efectos laterales. La segunda aproxi- 
mación de integración, la prueba basada en el uso, 
comienza la construcción del sistema probando aque- 
llas clases (llamadas clases independientes), que utili- 
zan muy pocas (o ninguna) clases servidoras. Después 
de que las clases independientes se prueban, esta secuen- 
cia de pruebas por capas de clases dependientes conti- 
núa hasta que se construye el sistema completo. A 
diferencia de la integración convencional, el uso de dri- 
vers y stubs como operaciones de reemplazo, debe evi- 
tarse siempre que sea posible. 


Cc VE 


la estrategia de integración de pruebas 00 se centra 
en grupos de clases que colaboran o se comunican 
de la misma manera. 


La prueba de agrupamiento [MGR94] es una fase 
en las pruebas de integración de software OO. Aquí, un 
agrupamiento de clases colaboradoras (determinadas 
por la revisión de los modelos CRC y objeto-relación), 
se prueba diseñando los casos de prueba, que intentan 
revelar errores en las colaboraciones. 


23.3.3. Pruebas de validación en un contexto OO 


Al nivel de sistema o de validación, los detalles de 
conexiones de clases desaparecen. Así como la vali- 
dación convencional, la validación del software OO 
se centra en las acciones visibles al usuario y salidas 
reconocibles desde el sistema. Para ayudar en la cons- 
trucción de las pruebas de validación, el probador debe 
utilizar los casos de uso (Capítulo 20), que son parte 
del modelo de análisis. Los casos de uso proporcionan 
un escenario, que tiene una gran similitud de errores 
con los revelados en los requisitos de interacción del 
usuario. 


Aporentemente, todos los métodos de pruebas 
de coja negm discutidos en el Capítulo 17 
son aplicables a ha 00, 


Los métodos de prueba convencionales de caja negra 
pueden usarse para realizar pruebas de validación. Ade- 
más, los casos de prueba deben derivarse del modelo de 
comportamiento del objeto y del diagrama de flujo de 
sucesos, creado como parte del ADO. 
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Los métodos de diseño de casos de prueba para soft- 

ware orientado a objetos continúan evolucionando. Sin 

embargo, una aproximación global al diseño de casos 

de prueba OO ha sido definida por Bernard [BER93]: 

l. Cada caso de prueba debe ser identificado separa- 
damente, y explícitamente asociado con la clase a 
probar. 

2. Debe declararse el propósito de la prueba. 

3. Debe desarrollarse una lista de pasos a seguir, como 


consecuencia de la prueba, pero además debe con- 
tener [BER93]: 


a. definición de una lista de estados, específicos 
para el objeto a probar. 

b. una lista de mensajes y operaciones, que se ejer- 
citarán como consecuencia de las pruebas. 

c. una lista de excepciones, que pueden ocurrir con- 
forme el objeto se comprueba. 

d. una lista de condiciones externas (por ejemplo, 
los cambios en el ambiente externo al software, 
que debe existir para conducir apropiadamente 
las pruebas). 

e. información adicional, que ayudará a la com- 


prensión e implementación de la prueba. 


A diferencia del diseño de pruebas convencional, que 
se conduce mediante una visión entrada-proceso-salida 
de software, o el detalle algorítmico de los módulos indi- 
viduales, la prueba orientada a objetos se enfoca en las 
secuencias de operaciones de diseño apropiadas para 
probar los estados de una clase. 


23.4.1. Implicaciones de los conceptos de OO 
al diseño de casos de prueba 


Como ya se ha visto, la clase es el objetivo del diseño 
de casos prueba. Debido a que los atributos y opera- 
ciones se encapsulan, las operaciones de prueba fuera 
de la clase son generalmente improductivas. A pesar de 
que la encapsulación es un concepto de diseño esen- 
cial para la OO, puede crear un obstáculo cuando se 
hacen las pruebas. Como menciona Binder [BIN94a], 
«la prueba requiere informes del estado abstracto y con- 
creto del objeto». La encapsulación puede dificultar un 
poco la obtención de esta información. A menos que se 
proporcionen operaciones incorporadas para conocer 
los valores para los atributos de la clase, una imagen 
instantánea del estado del objeto puede ser difícil de 
adquirir. 


3 Concepto de DOO que debe usarse con extrema precaución. 
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Referencia 


Una colección excelente de publicaciones, fuentes 
y bibliografías de pruebas OO puede encontrarse 
en www.rbsc.com 


La herencia también conduce a retos adicionalespara 
el diseñadorde casos de prueba. Ya se ha dicho que cada 
nuevo contexto de uso requiere repetir la prueba, aún y 
cuando se haya logrado la reutilización. Además, la 
herencia múltiple' complica mucho más las pruebas, 
incrementando el número de contextos para los que se 
requiere la prueba [BIN94a]. Si las subclases instan- 
ciadas de una superclase se utilizan dentro del mismo 
dominio de problema, es probable que el conjunto de 
casos de prueba derivados de la superclase puedan usar- 
se para la prueba de las subclases. De cualquier mane- 
ra, si la subclase se utiliza en un contexto enteramente 
diferente, los casos prueba de la superclase serán esca- 
samente aplicables, y tendrá que diseñar un nuevo con- 
junto de pruebas. 


23.4.2. Aplicabilidad de los métodos convencio- 
nales de diseño de casos de prueba 


Los métodos de «caja blanca» descritosen el Capítulo 17 
pueden aplicarse a las operaciones definidas para una cla- 
se. Técnicas como el camino básico, pruebas de bucle o 
técnicas de flujo de datos pueden ayudar a asegurar que 
se ha probado cada sentencia de la operación. De cual- 
quier modo, la estructura concisa de muchas operaciones 
de clase provoca que algunos defiendan que el esfuerzo 
aplicado a la prueba de «caja blanca» debe ser redirigido 
adecuadamente a las pruebas, a un nivel de clase. 

Los métodos de prueba de «caja negra» son tan apro- 
piados para los sistemas OO,como lo son para los siste- 
mas desarrollados utilizando los métodos convencionales 
de ingeniería de software. Como se dijo al principio del 
capítulo, los casos de uso pueden proporcionar datos Út- 
les en el diseño de pruebas de «caja negra», y pruebas 
basadas en estados [AMB9S5]. 


23.4.3. Pruebas basadas en errores! 


El objetivo de las pruebas basadas en errores dentro de 
un sistema OO,es diseñar pruebas que tengan una alta 
probabilidad de revelar fallos. Ya que el producto o sis- 
tema debe adaptarse a los requerimientos del cliente, la 


4 Las Secciones 23.4.3 a 23.4.6 han sido adaptadas de un artículo' 
de Brian Marick, divulgado en el grupo de noticias de internet 
comp.testing. Esta adaptación se ha incluido con el permiso del autor. 
Para adentrarse más en la discusión de este tema, véase [MAR94]. 
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planificación preliminar requerida para llevar a cabo la 
prueba basada en fallos comienza con el modelo de aná- 
lisis. El probador busca fallos posibles (por ejemplo, los 
aspectos de implementación del sistema que pueden 
manifestarse en defectos). Para determinar si existen 
estos fallos, los casos de prueba se diseñan para probar 
el diseño o código. 


CLAVE 


la estrategia consiste en hacer hipótesis de una serie 
de posiblesfallos, y luego conducir las pruebas 
para comprobar las hipótesis. 


Considérese un ejemplo simple”. Los ingenieros de 
software generalmente cometen errores en los límites 
del problema. Por ejemplo, cuando se prueba una ope- 
ración SQRT que genera errores para números negati- 
vos, se sabe probar los límites: un número negativo 
cercano al cero y el cero mismo. El «cero mismo» com- 
prueba si el programador ha cometido un error como: 


If(x> 0) calcular_la raíz cuadradal ); 


En lugar de lo correcto 
If[ x >= 0 ) calcular—-la—raíz-cuadradal ); 


Como otro ejemplo, considérese la expresión booleana 
siguiente: 


If (ag$£ Ib ]ilc) 


Consuo fp 


Ya que la prueba basada en fallos se da en un nivel 
detallada, se reservo mejor para las operaciones 
y dlases que son críticas a sospechosas. 


Las pruebas de multicondición y técnicas relaciona- 
das examinan las faltas posibles con toda seguridad en 
esta expresión, como, por ejemplo, 


$18 debería de ser ll 
| se ignoró donde se necesitaba 


Y debería haber un paréntesis alrededor de tb lle 


Para cada error probable, se diseñan casos de prue- 
ba, que forzarán a la condición incorrecta a fallar. En la 
expresión anterior, (a=0, b=0, c=0) forzarán a que la 
expresión se evalúe falsa. Si el £4 hubiera sido ll, el 
código hubiera dado el resultado incorrecto y el control 
habría seguido la rama errónea. 

Desde luego que la efectividad de estas técnicas 
depende de cómo los probadores perciben el «fallo pro- 
bable». Si los fallos verdaderos en un sistema OO se 


5El código presentado en ésta y en las siguientes secciones utiliza la 
sintaxis de C++. Para mayor información, véase cualquier buen libro 
de C++, 


413 


CAPÍTULO 23 PRUEBAS ORIENTADAS A OBJETOS 


perciben como «improbables», entonces esta aproxi- 
mación no es en realidad mejor que la técnica de prue- 
bas aleatorias. De cualquier manera, si los modelos de 
análisis y diseño pueden proporcionar la visión de lo 
que parece andar mal, entonces las pruebas basadas en 
errores pueden encontrar un número significativo de 
errores con esfuerzos relativamente pequeños. 

Las pruebas de integración buscan fallos probables 
en Operaciones o mensajes de conexión. Tres tipos de 
fallos se encuentran en este contexto: resultados ines- 
perados, uso incorrecto de operaciones/mensajes, invo- 
caciones incorrectas. Para determinar fallos probables 
cuando las funciones (operaciones) se invocan, se debe 
examinar el comportamiento de la operación. 

¿Qué tipo de fallos 


2 se encuentran en llamadas 
O operaciones y conexiones 
de mensajes? 


Las pruebas de integración se aplican tanto a atribu- 
tos como a operaciones. Los «comportamientos» de un 
objeto se definen por los valores que se asignan a sus 
atributos. Las pruebas deben verificar los atributos para 
determinar si se obtienen valores apropiados para los 
distintos tipos de comportamientos de los objetos. 

Es importante hacer notar que las pruebas de inte- 
gración intentan encontrar los errores en el objeto clien- 
te, no en el servidor. Dicho en términos comunes, el 
enfoque de las pruebas de integración es determinar si 
el error existe en el código de invocación, no en el códi- 
go invocado. La invocación a operacionesse utiliza como 
una pista, una forma de encontrar los requerimientos de 
la prueba que validen el código de invocación. 


23,4,4. Fl impacto de la programaciónOO en las 
pruebas 
Hay distintas maneras en que la programación orienta- 


da a objetos puede tener un impacto en las pruebas. 
Dependiendo del enfoque de la POO. 

Algunos tipos de fallos se vuelven menos probables 
(no vale la pena probar). 

+. Algunos tipos de fallos se vuelven más probables 
(vale la pena probar). 

Aparecen algunos tipos nuevos de fallos. 


e 


0 y espera que un programo funcione, 
oboble que vea un programa 
—axtrañorá fallos—. 

al 
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Cuando se invoca una operaciónes difícil decir exac- 
tamente qué código se ejecuta. Esto es, la operación 
debe pertenecer a una de muchas clases. Incluso, pue- 
de ser difícil determinar el tipo exacto o clase de un 
parámetro. Cuando el código lo acceda puede obtener- 
se un valor inesperado. La diferencia puede entenderse 
considerando la llamada a una función convencional: 


Xx = func(y); 


Para el softwareconvencional, el probador debe con- 
siderar todos los comportamientos atribuidos afunc y 
nada más. En un contexto OO,el probador debe consi- 
derar los comportamientos de base: :func( ), de deriva- 
da::func( ), y así sucesivamente. Cada vez quefunc se 
invoca, el probador debe considerar la unión de todos 
los comportamientos distintos. Esto es más fácil si se 
siguen prácticas de diseño OO adecuadas, y se limitan 
las diferencias entre superclases y subclases (en el len- 
guaje de C++, estas se llaman clases base y clases deri- 
vadas). 

La aproximación a las pruebas para clases derivadas 
y base es esencialmente la misma. La diferencia es de 
contabilidad. 

Probar las operaciones de clases es análogo a probar 
código que toma un parámetro de la función y luego la 
invoca. La herencia es una manera conveniente de pro- 
ducir operaciones polimórficas. En la llamada, lo que 
importa no es la herencia, sino el polimorfismo. La 
herencia hace que la búsqueda de los requisitos de prue- 
ba sea más directa. 

En virtud de la construcción y arquitectura de soft- 
ware, ¿existen algunos tipos de fallos más probables 
para un sistema OO, y otros menos probables? la res- 
puesta es «sí». Por ejemplo, a causa de que las ope- 
raciones OO son generalmente más pequeñas, se 
tiende a gastar más tiempo en la integración ya que 
existen más oportunidades de errores de integración. 
Así que los errores de integración se vuelven más pro- 
bables. 


23.4.5. Casos de prueba y jerarquía de clases 


Como se explicó previamente en este capítulo, la heren- 
cia no obvia la necesidad de probar todas las clases 
derivadas. De hecho, puede complicar el proceso de 


prueba. 
ave 


Aunque se haya comprobado bastante una clase base, 
tendrá que comprobar las clases derivadas de ella. 


Considérese la situación siguiente. Una clase base 
contiene operaciones heredadas y redefinidas. Una 
clase derivada redefine operaciones redefinidas para 
funcionar en un contexto local. Existe la pequeña duda 
de que la derivada: :redefinida( ) debe ser compro- 
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bada, porque representa un nuevo diseño y nuevo 
código. Pero, ¿la derivada: :heredada( ) debe ser 
recomprobada? 

Sila derivada:heredada(í ) invoca a redefini- 
da y el comportamiento de redefinida cambia, deri - 
vada: :heredada( ) podría manejar erróneamente 
el nuevo comportamiento. De este modo, se necesi- 
tan nuevas pruebas aunque el diseño y el código no 
hayan cambiado. Es importante hacer notar, sin 
embargo, que solo un subconjunto de todas las prue- 
bas para derivada ::heredada( ) deben rehacerse. 
Si parte del diseño y codificación para heredada no 
depende de redefinida (por ejemplo, no la llama ni 
llama ningún código que indirectamente la llame), 
ese código no necesita ser recomprobado en la clase 
derivada. 

Base:redefinida( ) y derivada: :redefinida( ) 
son dos operaciones diferentes con especificaciones e 
implementaciones diferentes. Cada una debería tener 
un conjunto de requisitos de prueba, derivadas de la 
especificación e implementación. Aquellos requisitos 
prueban errores probables: fallos de integración, fallos 
de condición, fallos de límites y así sucesivamente.Pero 
las operaciones es probable que sean similares por lo 
que el conjunto de requisitos de pruebas se solapan. 
Cuanto mejor sea el diseño OO, el solapamiento será 
mayor. Es necesario desarrollar las nuevas pruebas, solo 
para aquellos requisitos de derivada: :redefinida( ) 
que no fueron satisfechas por pruebas de base: :rede- 
finidal ). 

Para concluir, las pruebas de base: :redefinida(l ) 
se aplican a los objetos de la clase derivada. Las entra- 
das de las pruebas deben ser apropiadas para las clases 
base y derivada, pero los resultados esperados pueden 
diferir en la clase derivada. 


23.4.6. Diseño de pruebas basadas 
en el escenario 


Las pruebas basadas en los errores no localizan dos 
tipos de errores: (1) especificaciones incorrectas y (2) 
interacción entre subsistemas. Cuando ocurren errores 
asociados con especificaciones erróneas, el producto 
no realiza lo que el cliente desea. Puede que haga cosas 
incorrectas, o puede omitir funcionalidad importante. 
Pero en cualquier circunstancia, la calidad (cumpli- 
miento de requisitos) se sacrifica. Los errores asocia- 
dos con la interacción de subsistemas ocurren cuando 
el comportamiento de un subsistema crea circunstan- 
cias, (por ejemplo, sucesos, flujo de datos) que causan 
que el otro subsistema falle. 

Las pruebas basadas en el escenario se concentran 
en lo que el usuario hace, no en lo que el producto 
hace. Esto significa capturar las tareas (por medio de 
los casos de uso) que el usuario tiene que hacer, 
después aplicarlas a ellas y a sus variantes como 
pruebas. 
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e 
A 
La prueba basada en el escenario descubrirá errores 


que ocurren cuando cualquier actor interoctúa 
con el software 00. 


Los escenarios revelan errores de interacción. Pero 
para llevar a cabo esto, los casos de prueba deben ser 
más complejos y realistas que las pruebas basadas en 
los errores. Las pruebas basadas en el escenario tienden 
a validar subsistemas en una prueba sencilla (los usua- 
rios no se limitan al uso de un subsistema a la vez). 

A manera de ejemplo, considérese el diseño de prue- 
bas basadas en el escenario, para un editor de texto. Uti- 
lícense los siguientes casos: 


Caso de uso: Prepara la versión final. 


Aspectos de fondo: No es inusual imprimir el borrador «final», 
leerlo y descubrir algunos errores incómodos que no eran tan 
obvios en la imagen de la pantalla. Este caso de uso describe 
la secuencia de pasos que ocurren cuando esto pasa. 


1. Imprimir el documento entero. 
2. Rondar dentro del documento, cambiar algunas páginas. 
3. Al momento en que cada página se cambia, se imprime. 


4. Algunas veces se imprime una serie de páginas. 


Este escenario describe dos elementos: una prueba 
y unas necesidades específicas del usuario. Las necesi- 
dades del usuario son obvias: (1) un método para impri- 
mir una sola página y (2) un método para imprimir un 
rango de páginas. Hasta donde va la prueba, existe la 
necesidad de editar después de imprimir (así como lo 
contrario). El probador espera descubrir que la función 
de impresión causa errores en la función de edición; esto 
es, que las dos funciones de software sean totalmente 
independientes. 


Caso de uso: Impresión de una nueva copia. 

Aspectos de fondo: Se pide una copia reciente. Debe ser 
impresa: 

1. Abrir el documento 

2. Imprimirlo. 


3. Cerrar el documento. 


loro 


Aunque lo pruebo basada en el escenario tiene su mérito, 
encontrará uno recompensomayor revisondo los casos de 
uso cuando se desarrollan durante el ADO 


Una vez más, la aproximación de las pruebas es rela- 
tivamente obvia. Excepto que el documento no apare- 
ció fuera de ningún lugar. Fue creado en una tarea 
anterior. ¿La tarea anterior afecta a esta? 

En los editores modernos, los documentos registran 
como fueron impresos por última vez. Por omisión, se 
imprimen de la misma forma la siguiente vez. Después 
del escenario preparar la versión final, con solo selec- 
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cionar «imprimir» en el menú y presionando el botón 
«imprimir» en la caja de diálogo, se conseguirá que la 
última página corregida se imprima de nuevo. Así que, 
de acuerdo con el editor, el escenario correcto debería 
ser como el siguiente: 


Caso de uso: Imprimir una nueva copia. 
1. Abrir el documento. 
2. Seleccionar «imprimir» en el menú. 


3. Comprobar si se imprime un rango de páginas; si es así, pre- 
sionar para «imprimir» el documento entero. 


4. Presionar en el botón de impresión. 


5. Cerrar el documento. 


Pero este escenario indica una especificación poten- 
cial de error. El editor no hace lo que el usuario razo- 
nablemente espera. Los clientes generalmente pasarán 
por alto la opción de rango de páginas del paso 3 en el 
ejemplo anterior. Se incomodarán cuando enciendan la 
impresora y encuentren una página cuando ellos que- 
rían 100. Los clientes fastidiados significan errores de 
especificación. 

Un diseñador de casos de prueba debe olvidar la depen- 
dencia en un diseño de pruebas, pero es probable que el 
problema aparezca durante las pruebas. El probador ten- 
dría entonces que lidiar con la respuesta probable, «¿Esa 
es la forma como se supone que debe funcionar?». 


23.4.7. Las estructuras de pruebas superficiales 
y profundas 


La estructura superficial se refiere a la estructura visi- 
ble al exterior de un programa OO. Esto es, la estruc- 
tura que es inmediatamente obvia al usuario final. En 
vez de llevar a cabo funciones, los usuarios de muchos 
sistemas OO deben de proveerse de objetos para mani- 
pular de alguna forma. Pero sin importar la interfaz, las 
pruebas aún se basan en las tareas de los usuarios. Cap- 
turar estas tareas involucra comprensión, observación, 
y conversar con usuarios representativos (y tantos usua- 
rios no representativos como valga la pena considerar). 

Debe haber alguna diferencia en detalle con seguri- 
dad. Por ejemplo, en un sistema convencional con una 
interfaz orientada a comandos, el usuario debe usar la 
lista de comandos como una lista de control de pruebas. 
Si no existen escenarios de prueba para ejercitar un 
comando, las pruebas probablemente pasaron por alto 
algunas tareas del usuario (o la interfaz contiene coman- 
dos inútiles). En una interfaz basada en objetos, el veri- 
ficador debe usar la lista de todos los objetos, como una 
lista de control de pruebas. 


a 
a 
¡me 


lo estructura de pruebas se da en dos niveles: 
(1) pruebas que validan la estructura visible 
por el usuario final, (2) pruebas diseñadas 
para validar la estructura interna del programa. 
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Las mejores pruebas se dan cuando el diseñador 
observa al sistema de una manera nueva O poco con- 
vencional. Por ejemplo, si el sistema o producto tiene 
una interfaz basada en comandos, pruebas más com- 
pletas se darán si el diseñador de casos supone que las 
Operaciones son independientes de los objetos. Hacer 
preguntas como «¿Querrá el usuario usar esta operación 
——ue se aplica sólo al objeto scanner — mientras tra- 
baja con la impresora?». Cualquiera que sea el estilo de 
la interfaz, el diseño de casos de prueba que ejercita la 
estructura superficial debe usar ambos objetos y opera- 
ciones, como pistas que conduzcan a las tareas desa- 
percibidas. 

La estructura profunda se refiere a los detalles téc- 
nicos de un programa OO. Esto es, la estructura que se 
comprende examinando el diseño y/o el código. La veri- 
ficación de la estructura profunda está diseñada para 
ejercitar dependencias, comportamientosy mecanismos 
de comunicación, que han sido establecidos como par- 
te del diseño del objeto y del sistema (Capítulo 22) de 
software OO. 


Los modelos de análisis y diseño se utilizan como 
una base para la verificación de la estructura profunda. 
Por ejemplo, el diagrama objeto-relación o el diagrama 
de colaboración de subsistemas describe colaboracio- 
nes entre objetos y subsistemas, que no pueden ser visi- 
bles externamente. 

El diseño de casos de prueba entonces se pregunta: 
«¿Se ha capturado (como una prueba) alguna tarea que 
pruebe la colaboración anotada en el diagrama objeto 
relación, o en el diagrama de colaboración de subsiste- 
mas? Si no es así, ¿por qué no?» 

El diseño de representaciones de jerarquías de clases 
proporciona una visión de la estructura de herencia. La 
estructurajerárquica se utiliza en la verificación basada 
en errores. Considérese la situación en la cual una ope- 
ración llamada llamar_a( ) tiene un solo argumento, y 
ese argumento es una referencia a la clase base. ¿Qué 
ocurrirá cuando llamar_a( ) pase a la clase derivada? 
¿Cuáles serán las diferencias en comportamientoque pue- 
dan afectar a tal función? Las respuestas a estas pregun- 
tas pueden conducir al diseño de pruebas especializadas. 


En el Capítulo 17 se mencionó que la prueba de soft- 
ware comienza «en lo pequeño» y lentamente progresa 
hacia la prueba «a grande». La prueba «en pequeño», 
se enfoca en una sola clase y los métodos encapsulados 
por ella. La verificación y partición al azar son méto- 


dos que pueden usarse para ejercitar a una clase duran- 
te la prueba VO [KIR94]. 


23.5.1. La verificación al azar para clases OO 


A manera de ilustraciones sencillas de estos métodos, 
considérese una aplicación bancaria en la cual una cla- 
se cuenta contiene las siguientes operaciones: abrir, 
configurar, depositar, retirar, consultur saldo, resumen, 
Limitecrédito y cerrar [K1R94]. Cada una de estas ope- 
raciones debe aplicarse a cuenta, pero algunas limita- 
ciones (por ejemplo, la cuenta debe ser abierta antes de 
que otras operaciones puedan aplicársele, y cerrada des- 
pués de que todas las operaciones hayan sido comple- 
tadas) están implícitas en la naturaleza del probletna. 
Aún con estas limitaciones, existen muchas combina- 
ciones de operaciones. El registro de operaciones míni- 
ma de una instancia de cuenta incluye las siguientes 
Operaciones: 


Abrir - coniigurar - depositar - retirar - cerrar. 


Rionsiof) 


El número de combinaciones posibles para uno prueba 
aleatoria puede crecer mucha. Unaestrategia similar 
porolo pruebas de arrays ortogonales (Capitulo 17), 
puede usarse poro mejorar lo eficiencia de los pruebas. 


Esto representa la secuencia de verificación mínima 
para una cuenta. De cualquier modo, pueden existir una 
amplia variedad de combinaciones de operaciones posi- 
bles, dentro de esta secuencia: 


Abrir - configurar - depositar - [depositar | reti- 

rar | consultar saldo | resumen ¡ LimiteCrédito ]” - 

retirar - cerrar 

Pueden generarse una variedad de secuencias de ope- 
raciones diferentes al azar. Por ejemplo, 


Prueba r,: abri: - configurar — depositar - consultar 
saldo - resumen - retirar - cerrar. 
Prueba r,: abrir - coniigurar - depositar - retirar - 
depositar - consuitar saldo - LímiteCré- 
dito - retirar - cerrar. 
Estas y otras pruebas de orden aleatorio se realizan 
para probar diferentes registros de operaciones de ins- 


tancias de clases. 


23.5.2. Prueba de partición al nivel de clases 


Laprueba de partición reduce el número de casos de prue- 
ba requeridos para validar la clase, de la misma forma que 
la partición equivalente (Capítulo 17) para software con- 
vencional. Las entradas y salidas se clasifican, y los casos 
de prueba se diseñan, para validar cada categoría. Pero 
¿cómo se derivan las categorías de partición? 


4% ¿Qué opciones de pruebas 
* están disponibles a nivel 
de clases? 


La partición basada en estados clasifica las opera- 
ciones de clase basada en su habilidad de cambiar el 
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estado de la clase. Una vez más, considerando la clase 
cuenta, operaciones de estado incluyen a depositar y 
retirar, y considerando que las operaciones de no-esta- 
do incluyen a consultar saldo, resumen y LímiteCrédi- 
to, las pruebas se diseñan de manera que las operaciones 
que cambian el estado, y aquellas que no lo cambian, 
se ejerciten separadamente. Entonces: 


Prueba p,: abrir - configurar - depositar - depositar 
- retirar - retirar - cerrar. 

Prueba p,: abrir - configurar - depositar - resumen - 
Límitecrédito - retirar - cerrar. 


La prueba p, cambia el estado, mientras que la prue- 
ba p, ejercita las operaciones que no cambian el estado 
(excepto por las necesarias de la secuencia mínima de 
prueba). 


¿an JEBAS ORIENTADAS A OBJETOS 


ira aa Ur 


La partición basada en atributos clasifica las opera- 
ciones de clase basada en los atributos que ellas usan. 
Para la clase cuenta, los atributos saldo y LímiteCré- 
dito pueden usarse para definir particiones. Las opera- 
ciones se dividen en tres particiones: (1) Operaciones 
que utilizan LimiteCrédito, (2) operaciones que modi- 
fican Límitecrédito, y (3) operaciones que no utilizan 
o modifican Límitecrédito. Las secuencias de prueba 
se diseñan por cada partición. 

La partición basada en categorías clasifica las opera- 
ciones de la clase basadas en la función genérica que cada 
una lleva a cabo. Por ejemplo, las operaciones en la cla- 
se cuenta pueden clasificarse en operaciones de iniciali- 
zación (abrir, configurar),operacionescomputacionales 
(depositar, retirar), consultas (saldo, resumen, Límite- 
Crédito) y operaciones de terminación (cerrar). 


El diseño de casos de prueba se vuelve más complica- 
do cuando la integración del sistema OO comienza. Es 
en esta etapa en que la verificación de colaboraciones 
entre clases comienza. Para ilustrar «la generación de 
casos de prueba interclases» [KIR94], se expande el 
ejemplo de la aplicación bancaria introducida en la Sec- 
ción 23.5, para incluir las clases y colaboraciones de la 
Figura 23.2. La dirección de las flechas en la Figura 
indica que se invocan como consecuencia de colabora- 
ciones implícitas a los mensajes. 

Así como la verificación de clases individuales, la 
verificación de colaboraciones de clases puede com- 
pletarse aplicando métodos de partición y al azar, así 
como pruebas basadas en el escenario y pruebas de com- 
portamiento. 


Gs 


23.6.1. Prueba de múltiples clases 


Kirani y Tsai [KIR94] sugieren la secuencia siguiente 
de pasos, para generar casos de prueba aleatorios para 
múltiples clases: 

1, Para cada clase cliente, utilice la lista de operacio- 
nes de clase, para generar una serie de secuencias de 
pruebas al azar. Las operaciones enviarán mensajes 
a las otras clases servidoras. 

. Para cada mensaje que se genere, determine la clase 
colaboradora y la operación correspondiente en el 
objeto servidor. 

. Para cada operación en el objeto servidor (invocada 

por mensajes enviados por el objeto cliente), deter- 

mine los mensajes que transmite. 

Para cada uno de los mensajes, determine el siguiente 

nivel de operaciones que son invocadas, e incorpore 

éstas a la secuencia de pruebas. 

Para ilustrar [KIR 94], considérese una secuencia de 


operaciones para la clase banco relativa a una clase 
ATM (Figura 23.2): 


> 
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verifCuenta verifNIP [[verifPoliza 
regRetirar]/ regDepositar | regInfoCuenta J” 


Tarjetalnsertada 


E ntoscia VerificarCuenta 
DEGÓSio VerificarPIN 
Sd VerificarPolítica 
RegRetirar 
AT EstadoCuenta ReqDepósito ValidarPIN 


Terminar ValidarCuenta 


InfoCuenta 


Interfaz | - 
de usuario [ VerificarEstado AbrirCuenta 
TT EstadoDepósito ceci TarjetaAutorizo 
ImprimirEstadoCuenta DE noo TipoCuenta 
LeerlnfoTarjeta esaulorizar Balance 
CerrarCuenta 


Datirne 
neuíal 


Depósito 


Cerra 
Cuenta validación: 
| de información 


FIGURA 23.2. Grafo de colaboraciones de clase 
para una aplicación bancaria [KIR94]. 


ObtenerCantidadEfectivo 


Un caso de prueba aleatorio para la clase banco 
podría ser: 


Prueba r, = verifCuenta - verifNIP - reqDepositar 


Con la finalidad de considerar a los colaboradores 
involucrados en esta prueba, los mensajes asociados con 
cada una de las operaciones mencionadas en el caso de 
prueba r, deben ser tomados en cuenta. Banco debe cola- 
borar con infoValidación para ejecutar verifCuenta y 
verifNIP. Banco debe colaborar con cuenta para ejecu- 
tar regDepositar. De aquí que un nuevo caso de prueba, 
que ejercite estas colaboraciones, es: 


[validCuenta 
- [ValidNIP, 


infovalidación) 


Prueba IF, = VerifCuentan 


- VerifNIP, 


Banco 


- regDepositar - [Depositar,.....) 


infovalidación) 


La aproximación para la prueba de partición de múl- 
tiples clases es similar a la aproximación usada para la 
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prueba de partición de clases individuales. La manera 
como una sola clase se particiona se discutió en la Sec- 
ción 23.4.5. De cualquier modo, la secuencia de prue- 
bas se extiende para incluir aquellas operaciones que se 
invocan por los mensajes a clases colaboradoras. Una 
aproximación alternativa basa las pruebas por partición 
en las interfaces de una clase en particular. Haciendo 
referencia a la Figura 23.2, la clase banco recibe men- 
sajes de las clases ATM y Cajero. Los métodos inclui- 
dos en banco pueden probarse particionándolos en 
aquellos que sirven a ATM y aquellos que sirven a Caje- 
ro.La partición basada en estados (Sección 23.4.9), pue- 
de usarse para refinar aún más las particiones. 


23.6.2. Prueba derivada de los modelos 
de comportamiento 


En el Capítulo 2 1 se discutióel uso del diagrama de tran- 
sición de estados, como el modelo que representa el com- 
portamiento dinámico de una clase. El DTE (Diagrama 
de transición de estados) para una clase puede usarse 
para ayudar a derivar una secuencia de pruebas, que ejer- 
citarán el comportamiento dinámico de la clase (y aque- 
llas clases que colaboran con ella). La Figura 23.3 
[KIR94] ilustra una DTE para la clase cuenta explica- 
da con anterioridad”. Con referenciaa la Figura, las tran- 
siciones iniciales se mueven por los estados cuenta vacía 
y configura cuenta. Un retiro final y cierre causan que 
la clase cuenta haga transiciones a los estados nohace- 
trabajo de cuenta y cuenta muerta, respectivamente. 


Preparar 
cuenta 


Preparar 
cuenta 


Depósito (inicial) 


Depósito 


Trabajo 
con la 
cuenta 


Balance 
Crédito 
InfoCuenta 


0) Retirar 


Retirar todo (final) 


Cuenta 
no operativa 


Eliminar 
Cuenta 


FIGURA 23.3. Diagrama de transición de estados 
para la clase cuenta [KIR94]. 


Las pruebas a diseñarse deben alcanzar una cober- 
tura de todos los estados [KIR94]. Eso significaque las 
secuencias de operaciones deben causar que la clase 
cuenta haga transiciones por todos los estados: 


6 La simbologia UML se utiliza para el DTE que se ilustra enla Figura 
23.3. Difiere ligeramente de la simbología usada para los DTEs en la 
parte tres de este libro. 


418 


Prueba s,: abrir -preparar cuenta - depositar (ini- 
cial) - retiro (final) - cerrar 


Nótese que esta secuencia es idéntica a la secuencia 
mínima de pruebas, discutida en la Sección 23.5.1. Si 
se agregan secuenciasde prueba adicionalesa la secuen- 
cia mínima: 

Prueba s,: abrir - preparar cuenta - depositar (ini- 


cial)- saldo - crédito - retiro (final) - 
cerrar. 


Prueba s,: preparar cuenta - depositar (inicial)- 
retiro - infoCuenta - retiro(final) cerrar. 


Se pueden derivar aún más casos de prueba, para ase- 
gurarse de que todos los comportamientos para la cla- 
se han sido adecuadamente ejercitados. En situaciones 
en las que el comportamiento de la clases, resulte en 
una colaboración con una o más clase se utilizan múl- 
tiples DTESs para registrar el flujo de comportamientos 
del sistema. 

El modelo de estado puede serrecorrido «primero a 
lo ancho» [MGR94]. En este contexto, primero a lo 
ancho implica que un caso de prueba valida una sola 
transición y después, cuando se va a verificar una nue- 
va transición, se utilizan sólo las transiciones previa- 
mente verificadas. 

Considérese el objeto tarjeta-de-crédito de la Sec- 
ción 23.2.2. El estado inicial de tarjeta-de-crédito 
es indefinido (es decir, no se ha proporcionado un 
número de tarjeta de crédito). Una vez leída la tarjeta 
de crédito durante una venta, el objeto asume un esta- 
do definido; esto significa que los atributos número 
tarjeta y fecha expiración, se definen junto con iden- 
tificadores específicos del banco. La tarjeta de crédi- 
to se envía, cuando se envía la autorización, y es 
aprobada cuando la autorización se recibe. La transi- 
ción de tarjeta-de-créditode un estado a otro puede 
probarse generando casos de prueba, que hagan que la 
transición ocurra. Un enfoque «primero a lo ancho» 
en este tipo de pruebas, puede no validar el envío antes 
de que se ejercite indefinida y definida. Si lo hiciera, 
haría uso de transiciones que no han sido verificadas 
con anterioridad, y violaría el criterio «primero a lo 


ancho». 


Referencia Web| * 


Uno extensa colección de ((consejos sobre 
pruebas 00» (incluyendo muchos referencias 
útiles) puede encontrarse en: 
www.kinetica.com/ootips/ 


www.elsolucionario.net 


CAPÍTULO 23 PRUEBAS ORIENTADAS A OBJETOS 


El objetivo global de la verificación orientada a objetos 
-encontrar el máximo número de errores con un míni- 
mo de esfuerzo—, es idéntico al objetivo de prueba del 
software convencional. Pero la estrategia y tácticas para 
la prueba OO difieren de modo significativo. La visión 
de verificación se amplía, para incluir la revisión de 
ambos modelos de diseño y de análisis. 

En resumen, el enfoque de prueba se aleja del com- 
ponente procedimental (el módulo) hacia la clase. Ya que 
los modelos de análisis y diseño OO y el código fuente 
resultante se acoplan semánticamente, la prueba (a mane- 
ra de revisiones técnicas formales) comienzaen estas acti- 
vidades de ingeniería. Por esta razón, la revisión de los 
métodos CRC, objeto-relación y objeto-comportamiento, 
pueden verse como una primera etapa de prueba. 

Una vez que la POO ha sido concluida, las prue- 
bas de unidad se aplican a cada clase. El diseño de 
pruebas para una clase utiliza una variedad de méto- 
dos: pruebas basadas en errores, las pruebas al azar 
y las pruebas por partición. Cada uno de estos méto- 
dos ejercita las operaciones encapsuladas por la cla- 
se. Las secuencias de pruebas se diseñan para 
asegurarse de que las operaciones relevantes se ejer- 


citen. El estado de la clase representada por los valo- 
res de sus atributos se examina, para determinar si 
persisten errores. 

La prueba de integración puede llevarse a cabo utili- 
zando una estrategia basada en hilos O basada en el uso. 
La estrategia basada en hilos integra el conjunto de cla- 
ses, que colaboran para responder a una entrada o suce- 
so. Las pruebas basadas en el uso construyen el sistema 
en capas, comenzando con aquellas clases que no usan 
clases servidoras. Los métodos de diseño de integración 
de casos de prueba pueden usar pruebas al azar y por par- 
tición. En suma, las pruebas basadas en el escenario y las 
pruebas derivadasde los modelos de comportamiento pue- 
den usarse para verificar una clase y sus colaboraciones. 
Una secuencia de pruebas registra el flujo de operacio- 
nes, a través de las colaboraciones de clases. 

La prueba de validación de sistemas OO está orien- 
tada a caja negra y puede completarse aplicando los 
mismos métodos de prueba de caja de negra discutidos 
para el software convencional. Sin embargo, las prue- 
bas basadas en el escenario dominan la validación de 
sistemas OO, haciendo que el caso de uso sea el con- 
ductor primario para las pruebas de validación. 


[AMB95] Ambler, S., «Using Use Cases», Software Deve- 
lopment, Julio de 1995, pp. 53-61. 

[BER93] Berard, E.V., Essays on Ohject-Oriented Software 
Engineering, vol. 1, Addison-Wesley, 1993. 

[BIN94a] Binder, R.V., «Testing Object-Oriented Systems: 
A Status Report», American Programmer, vol. 7,n.? 4, 
Abril de 1994, pp. 23-28. 

[BIN94b] Binder, R.V., «Object-Oriented Software Testing», 
CACM, vol. 37, 1n.* 9, Septiembre de 1994, p. 29. 

[CHA93] DeChampeaux, D., D. Lea y P. Faure, Object-Orien- 
ted System Development, Addison-Wesley, 1993. 

[FIC92] Fichman, R., y €. Kemerer, «Object-Oriented and 
conceptual Design Methodologies», Computer, vol. 25, 
n.” 10, Octubre de 1992, pp. 22-39. 


[KIR94] Kirani, S., y W.T. Tsai, «Specification and Verifica- 
tion of Object-Oriented Programs», Technical Report TR 
94-96, Computer Science Department, University of Min- 
nesota. Diciembre de 1994. 


[LIN94] Lindland, O.I., et al., «Understanding Quality in Con- 
ceptual Modeling», IEEE Software, vol. 11, n.* 4, Julio de 
1994, pp. 42-49. 


[MAR94] Marick, B., The Craft of Software Testing, Prenti- 
ce Hall. 1994, 


[MGR94] McGregor, J.D., y T.D. Korson, «Integrated Object- 
Oriented Testing and Development Processes», CACM, 
vol. 37, n." 9, Septiembre de 1994, pp. 59-77. 


23.1. Describa con sus propias palabras por qué la clase es 
la más pequeña unidad razonable para las pruebas dentro de 
un sistema OO. 


23.2, ¿Por qué debemos probar de nuevo las subclases ins- 
tanciadas de una clase existente si ésta ya ha sido probada por 
completo? ¿Podemos usar los casos de prueba diseñados para 
dicha clase? 


23.3. ¿Por qué debe comenzar la «prueba» con las activida- 
des de AOO y DOO? 
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23.4. Derive un conjunto de tarjetas índice CRC para Hogar- 
Seguro y ejecute los pasos señalados en la Sección 23.2.2 para 
determinar si existen inconsistencias. 


23.5. ¿Cuál es la diferencia entre las estrategias basadas en hilos 
y aquellas estrategias basadas en uso para las pruebas de inte- 
gración? ¿Cóme cabe la prueba de agrupación en ellas? 


23.6. Aplique la prueba aleatoria y la de partición a tres cla- 
ses definidas en el diseño del sistema HogarSeguro produci- 
do por usted en el Problema 22.12. 
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Produzca casos de prueba que indiquen las secuencias de ope- 
raciones que se invocarán. 

23.7. Aplique la prueba de múltiples clases y las pruebas deri- 
vadas del modelo de comportamiento al diseño de HogarSe- 
guro. 

23.8. Obtenga pruebas usando los métodos señalados en los 
Problemas 23.6 y 23.7 para el sistema SSRB descrito en el 
Problema 22.13. 

23.9. Obtenga pruebas usando los métodos señalados en los 
Problemas 23.6 y 23.7 para el juego de vídeo considerado en 
el Problema 22.14. 


23.10.Obtenga pruebas usando los métodos señalados en los 
Problemas 23.6 y 23.7 para el sistema de e-mail considerado 
en el Problema 22,15. 


23.11. Obtenga pruebas usando los métodos señalados en los 
Problemas 23.6 y 23.7 para el sistema ATC considerado en el 
Problema 22.16. 


23.12. Obtenga cuatro pruebas adicionales usando cada 
uno de los métodos señalados en los Problemas 23.6 y 23.7 
para la aplicación bancaria presentada en las Secciones 23.5 
y 23.6. 


La literatura para la prueba OO es relativamente escasa, aun- 
que se ha expandido algo en años recientes. Binder (Testing 
Ohject-Oriented Systems: Models, Patterns, and Tools, Addi- 
son-Wesley,2000) ha escrito el tratamiento más extenso del 
tema publicado hasta la fecha. Siegel y Muller (Object Orien- 
ted Software Testing: A Hierarchical Approach, Wiley, 1996) 
propusieron una estrategia práctica de prueba para sistemas 
00. Marick (The Craft of Software Testing: Subsystem Tes- 
ting Including Ohject-Based and Ohject-Oriented Testing, 
Prentice Hall, 1995) cubre la prueba tanto para software con- 
vencional como para OO. 

Antologías de publicaciones sobre prueba VO han sido edi- 
tadas por Kung et al. (Testing Object-Oriented Software, IEEE 
Computer Society, 1998) y Braude (Ohject Oriented Analysis, 
Design and Testing: Selected Readings, IEEE Computer 
Society, 1998). Estos tutoriales de IEEE proporcionan una inte- 
resante perspectiva histórica en el desarrollo de prueba OO. 
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Jorgenesen (Software Testing: A Cruftsman 's Approuch, 
CRC Press, 1995) y McGregor y Sykes (Ohject-Oriented 
Software Development, Van Nostrand Reinhold, 1992) pre- 
senta capítulos dedicados al tema. Beizer (Black-BoxTes- 
ting, Wiley, 1995) analiza una variedad de métodos de 
diseño de casos prueba los cuales son apropiados en un con- 
texto OO. 

Binder (Testing Object-Oriented Systems, Addison-Wes- 
ley, 1996) y Marick [MAR94] presenta tratamientos detalla- 
dos de prueba OO. En resumen, muchas de las fuentes 
anotadas para el Capítulo 17 son en general aplicables a la 
prueba OO. 

Una amplia variedad de fuentes de información de prue- 
ba orientada a objetos y temas relacionados se encuentran dis- 
ponibles en intemet. Una lista reciente a sitios (páginas) web 
que son relevantes a la prueba OO puede encontrarse en 
http: //www.pressman5.com 
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MÉTRICAS TÉCNICAS PARA SISTEMAS 
ORIENTADOS A OBJETOS 


N secciones anteriores de este libro, se mencionó que las métricas y mediciones son com- 

ponentes clave para cualquier disciplina de ingeniería —y la ingeniería de software orien- 

ada a objetos no es una excepción —. Desgraciadamente, el uso de métricas para sistemas 

00 ha progresado mucho más despacio que'el uso de otros métodos OO. Ed Berard [BER95] 
mencionó la ironía de las mediciones, cuando declaraba que: 


La gente involucrada en el software parece tener una relación amor-odio con las métricas. Par una par- 
te, menosprecian y desconfían de cualquier cosa que parezca O suene a medición. Son rápidos, bastante rápi- 
dos para señalar las «imperfecciones», en los argumentos de cualquiera que hable acerca de las mediciones 
a los productos de software, procesos de software, y (especialmente) personas involucradas en software. 
Por otra parte, esta misma gente parece no tener problemas al identificar qué lenguaje de programación es 
el mejor, las estupideces que los administradores hacen para «arruinar» proyectos, y la metodología de tra- 
bajo en qué situaciones. 

La «relación amor-odio» que Berard declara es real. Más aun, como los sistemas OO+se 
encuentran cada vez más implantados, es esencial que los ingenieros en software posean medi- 
ciones cuantitativas, para la evaluación de calidad de diseños, a niveles arquitectónicos y de 
componentes. 

Estas mediciones permiten al ingeniero evaluar el software al inicio del proceso, haciendo 


cambios que reducirán la complejidad y mejorarán la viabilidad, a largo plazo, del producto 
final. 


VISTAZO RÁPIDO 


¿Qué es? Construir software OO ha sido la arquitectura OO,las clases y sub- riores. Los resultados del análisis son 


una actividad de ingeniería, que confía 
más en el juicio, folklore y referencias 
cualitativas, queenla evaluación cuan- 
titativa. Las métricas OO se han intro- 
ducido para ayudar a un ingeniero del 
software a usar el análisis cuantitativo, 
para evaluar la calidad en el diseño 
antes de que un sistema se construya. 
El enfoque de métricas OO está en la 
clase —la piedra fundamental de la 
arquitectura OO—, 


¿Quién lo hace? Los ingenieros del soft- 


ware se ayudan de las métricas para 
construir software de mayor calidad. 


¿Por qué es importante? Como se 


expuso en el vistazo rápido del Capí- 
tulo 19,1a evaluación cualitativa de 
software debe complementarse con el 
análisis cuantitativo. Un ingeniero del 
software necesita un criterio objetivo 
para ayudarse a conducir el diseño de 


sistemasque conforman la arquitectu- 
ra, las operaciones y atributos que 
constituyen una clase. El comprobador 
necesita las referencias cuantitativas, 
que le ayudarán en la selección de 
casos de prueba y sus objetivos. Las 
métricas técnicas proporcionan una 
base desdela cual el análisis, el dise- 
ño y la verificación pueden conducirse 
de manera más objetiva, y serevalua- 
dos más cuantitativamente. 


¿Cuáles son los pasos? El primer paso 


en el proceso de medición es deducir 
las mediciones de software y métricas 
que pudieran ser apropiadas para la 
representación del software en consi- 
deración. Después, se recolectan los 
datos requeridos para aplicar las métri- 
cas formuladas. Una vez computados, 
se analizan basándose en orientacio- 
nes preestablecidas y en datos ante- 


421 


interpretados para obtener una visión 
inherente a la calidad del software, y 
los resultados de la interpretación con- 
ducen a la modificación de resultados 
de trabajo deducidos del análisis, dise- 
ño, codificación o prueba. 


¿Cuál es el producto obtenido? Las 


métricas de software que se calculan 
mediante losdatos recolectados de los 
modelos de análisis y diseño, código 
fuente y casos de prueba. 


¿Cómo puedo estar seguro de que 


lo he hecho correctamente? Debe 
establecer los objetivos de las medi- 
ciones antes de que la recolección de 
datos comience, definiendo cada métri- 
ca OO de manera concreta. Definir 
solamente algunas métricas y después 
utilizarlas, para obtener una vista inhe- 
rente a la calidad de un producto de 
ingeniería de software. 
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Los objetivos primarios para las métricas orientadas a 
objetos no son diferentes de aquellos de las métricas 
desarrolladas para el software convencional: 


para entender mejor la calidad del producto. 
para evaluar la efectividad del proceso. 


para mejorar la calidad del trabajo llevado a cabo al 
nivel del proyecto. 


Cada uno de estos objetivos es importante, pero para 
el ingeniero de software la calidad del producto debe 
ser lo más importante. Pero ¿cómo medir la calidad de 
un sistema 00? ¿Qué característicasdel modelo de dise- 
ño pueden y deben evaluarse para determinar si el sis- 
tema será fácil de implementar, fácil de verificar, simple 
de modificar y, lo más importante, aceptable para los 
usuarios finales? Estas preguntas serán contestadas en 
la parte restante del capítulo. 


Las métricas para cualquier producto de ingeniería son 
reguladas por las características únicas del producto. 
Por ejemplo, sería inútil o sin sentido contar las millas 
por galón de consumo para un automóvil eléctrico. La 
métrica es firme para los automóviles convencionales 
(es decir, impulsados por sistemas de combustión inter- 
na a gasolina) pero no se aplica cuando el modo de pro- 
pulsión cambia radicalmente. El software orientado a 
objetos es fundamentalmente diferente del software 
desarrollado con el uso de métodos convencionales. Por 
estarazón, las métricas para sistemas OO deben ser afi- 
nadas a las características que distinguen al software 
00 del software convencional. 

Berard [BER95] define cinco características que 
regulan las métricas especializadas: Localización, 
encapsulación, ocultamiento de información, herencia 
y técnicas de abstracción de objetos. Cada una de estas 
características se discute brevemente en las secciones 
siguientes". 


Referencia Web 


Una extensión de búsqueda para métricas DO la puedes obtener 
en: www.objenv.com /cetus / 00_metrics.html 


24.2.1. Localización 


La localización es una característica del software que 
indica la manera en que la información se concentra en 
un programa. Por ejemplo, los métodos convenciona- 
les para la descomposiciónfuncional organizan la infor- 
mación en torno a las funciones que son típicamente 
implementadas como módulos procedimentales. Los 
métodos manejados por datos localizan la información 
en tomo a estructuras de datos específicas. En el con- 
texto OO, la información se concentra por la encapsu- 
lación de datos y procesos dentro de los límites de una 
clase u objeto. 


| Este estudio ha sido adaptado de [BER95] 
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Ya que el software convencional enfatiza la función 
como un mecanismo de localización, las métricas de * 
software se han enfocado a la estructura interna o fun- 


ciones de complejidad (por ejemplo, longitud del módu- 
lo, cohesión o complejidad ciclomática), o a la manera 
como las funciones se conectan entre sí (acoplamiento 
de módulos). 


Métricos técnicas pam software convencional 
se describenen el Capítulo 19. 


Puesto que la clase es la unidad básica de un siste- 
ma OO, la localización se basa en los objetos. Por esta 
razón, las métricas deben aplicarse a la clase (objeto), 
como a una entidad completa. En suma, la relación entre 
operaciones (funciones) y clases no es necesariamente 
uno a uno. Por lo tanto, las métricas que reflejan la mane- 
ra en la que las clases colaboran deben ser capaces de 
acomodarse a relaciones uno a muchos y muchos a uno. 


24.2.2, Encapsulación 


Berard [BER95] define la encapsulación como el 
«empaquetamiento (o ligamento) de una colección de 
elementos. Ejemplos de bajo nivel de encapsulación 
[para software convencional] incluyen registros y matri- 
ces, [y] subprogramas (por ejemplo, procedimientos, 
funciones, subrutinas y párrafos), son mecanismos de 
nivel medio para la encapsulación.» 


Referencia cruzada 


Los conceptos básicos de diseño se describen 
enel Capitulo 13. Su aplicación al sofware DO 
se discute en el Capítulo 20, 


Para los sistemas OO, la encapsulación engloba las 
responsabilidades de una clase, incluyendo sus atribu- 
tos (y otras clases para objetos agregados) y operacio- 
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nes, y los estados de la clase, definidos por valores de 
atributos específicos. 

La encapsulación influye en las métricas, cambian- 
do el enfoque de las mediciones de un módulo simple, 
a un paquete de datos (atributos) y módulos de proce- 
so (operaciones). 

En suma, la encapsulación eleva la medición a un 
nivel de abstracción más alto. 

Por ejemplo, más adelante en este capítulo se intro- 
ducirán las métricas asociadas con el número de opera- 
ciones por clase. Contrasta este nivel de abstracción con 
las métricas que se centran en contar condiciones boo- 
leanas (complejidad ciclomática) o en contar líneas de 
código. 


24.23. Ocultación de información 


La ocultación de información suprime (u oculta) los 
detalles operacionales de un componente de programa. 
Solo se proporciona la información necesaria para acce- 
der al componente a aquellos otros componentes que 
deseen acceder. 

Un sistema OO bien diseñado debe implementar 
ocultación de información. Por esta razón, las métricas 
que proporcionan una indicación del grado de oculta- 


ción logrado suministran un'indicio de la calidad del 
diseño OO. 


24,2,4, Herencia 


La herencia es un mecanismo que habilita las respon- 
sabilidades de un objeto, para propagarse a otros obje- 
tos. La herencia ocurre a través de todos los niveles de 
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una jerarquía de clases. En general, el software con- 
vencional no cumple esta característica. 

Ya que la herencia es una característica vital en 
muchos sistemas OO, muchos métodos OO se centran 
en ella. Los ejemplos (discutidos más adelante en este 
capítulo) incluyen múltiples hijos (instancias inmedia- 
tas de una clase), múltiples padres (generalizaciones 
inmediatas), y jerarquías de clase a un nivel de anída- 
miento (profundidad de una clase en la jerarquía de 
herencia). 


24.2,5, Abstracción 


La abstracción es un mecanismo que permite al dise- 
ñador concentrarse en los detalles esenciales de un com- 
ponente de programa (ya sean datos o procesos), 
prestando poca atención a los detalles de bajo nivel. 
Como Berard declara: «la abstracción es un concepto 
relativo. A medida que se mueve a niveles más altos de 
abstracción, se ignoran más y más detalles, es decir, se 
tiene una visión más general de un concepto o elemen- 
to. A medida que se mueve a niveles de abstracción más 
bajos, se introducen más detalles, es decir, se tiene una 
visión más específica de un concepto o elemento.» 

Ya que una clase es una abstracción, que puede visua- 
lizarse a diferentes niveles de detalle de diferentes de 
maneras (por ejemplo, como una lista de operaciones, 
como una secuencia de estados, como una serie de cola- 
boraciones), las métricas OO representan abstracciones 
en términos de mediciones de una clase (por ejemplo, 
número de instancias por clase por aplicación, número 
O clases parametrizadas por aplicación, y proporción de 
clases parametrizadas con clases no parametrizadas). 


Mucho acerca del diseño orientado a objetos es sub- 
jetivo —un diseñador experimentado «sabe» como 
caracterizar a un sistema OO, para que implemente 
efectivamente los requerimientos del cliente —. Pero, 
cuando un modelo de diseño OO crece en tamaño y 
complejidad, una visión más objetiva de las caracte- 
rísticas del diseño puede beneficiar al diseñador expe- 
rimentado (que adquiere vista adicional), y al novato 
(que obtiene indicadores de calidad que de otra mane- 
ra no estarían disponibles). 


¿Qué características pueden 
%' medirse cuando se evalúa 
un diseño 00? 


Como parte de un tratamiento detallado de las métri- 
cas de software para sistemas OO, Whitmire [WH197] 
describe nueve características distintas y medibles de 
un diseño OO: 

Tamano. El tamaño se define en términos de cuatro 
enfoques: población, volumen, longitud y funcionali- 
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dad. La población se mide haciendo un recuento de las 
entidades OO,como las clases u operaciones. Las medi- 
das de volumen son idénticas a las de población, pero 
se realizan dinámicamente - e n un instante de tiempo 
dado—.La longitud es la medida de una cadena de ele- 
mentos de diseño interconectados (por ejemplo, la pro- 
fundidad de un árbol de herencia es una medida de 
longitud). Las métricas de funcionalidad proporcionan 
una indicación indirecta del valor entregado al cliente 
por una aplicación OO. 

Complejidad. Así como el tamaño, existen diferen- 
tes enfoques de la complejidad del software [2US97]. 
Whitmire la define en términos de característicasestruc- 
turales, examinando cómo se interrelacionan las clases 
de un diseño OO con otras. 

Acoplamiento. Las conexiones físicas entre los ele- 
mentos del diseño OO (por ejemplo, el número de cola- 
boraciones entre clases o el número de mensajes 
intercambiados entre objetos), representan el acopla- 
miento dentro de un sistema OO. 
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Suficiencia. Whitmire define la suficiencia como «el 
grado en que una abstracción posee los rasgos mínimos 
necesarios, O el grado en que una componente de diseño 
posee características en su abstracción, desde el punto 
de vista de la aplicación actual», Dicho de otro modo, 
se hace la pregunta: «¿qué propiedades tiene que poseer 
esta abstracción (clase) para que sea Útil? [WHI97]. 
En esencia, un componente de diseño (por ejemplo, una 
clase) es suficiente si refleja completamente todas las 
propiedades del objeto dominio de la aplicación que se 
modela; esto es lo que significa que la abstracción 
(clase), posea los rasgos imprescindibles. 


los decisiones para las cuales 
je contar con el folklore y mitos pueden 
vantilativos. 


Integridad. La Única diferencia entre integridad y sufi- 
ciencia es «el conjunto de características, contra las que 
se comparan la abstracción O componente de diseño 
[WHI97]». La suficiencia compara la abstracción, desde 
el punto de vista de la aplicación en cuestión. La integri- 
dad considera muchos puntos de vista, preguntándose: 
«¿Qué propiedades se requieren para representar com- 
pletamente el objeto dominio del problema?» Ya que los 
criterios de integridad consideran diferentes puntos de 
vista, hay una implicación indirecta, acerca del grado en 
que la abstraccióno componente de diseño puede serreu- 
tilizada. 

Cohesión. Así como su correspondienteen el software 
convencional, un componente OO debe diseñarse de 
manera que posea todas las operaciones trabajando con- 
juntamente para alcanzarun propósito Único y bien defi- 
nido. La cohesión de una clase se determina examinando 
el grado en que «el conjunto de propiedades que posee 
sea parte del diseño o dominio del problema» [WHI97]. 


Referencia Web 


Un informe técnico de la NASA, que aborda métricas de 
calidad para sistemas 00, puede descargarse del 
satc.gstc.nasa.gov / support /index.html 


Originalidad. Una característica similar a la simpli- 
cidad, la originalidad (aplicada tanto a Operaciones como 
a clases) es el grado en que una operación es atómica; 
esto significa que la operación no puede ser construida 
fuera de una secuencia de otras operaciones contenidas 
dentro de una clase. Una clase que exhibe un alto grado 
de originalidadencapsula solamente las operaciones pri- 
mitivas. 

Similitud. Esta métrica indica el grado en que dos o 
más clases son similaresen términos de estructura, com- 
portamiento, función o propósito. 

Volatilidad. Como se mencionó anteriormente en 
este libro, pueden ocurrir cambios en el diseño cuando 
se modifiquen los requisitos, O cuando ocurran modifi- 
caciones en otras partes de la aplicación, resultando una 
adaptación obligatoria del componente de diseño en 
cuestión. La volatilidad de un componente de diseño 
00 mide la probabilidad de que un cambio ocurra. 

La descripción de métricas de Whitmire para estas 
características de diseño se encuentra fuera del ámbito 


de este libro.*Los lectores interesados deben consultar 
[WHI97], para más detalles. 

En realidad, las métricas técnicas para sistemas 
00 pueden aplicarse no sólo al modelo de diseño, 
sino también al modelo de análisis. En las secciones 
siguientes, se exploran las métricas que proporcio- 
nan un indicador de calidad, al nivel de las clases DO 
y al nivel de operación. En suma, las métricas apli- 
cables al manejo de proyectos y pruebas también se 
comentarán. 

La clase es la unidad fundamental de un sistema OO. 


Por esta razón, las medidas y métricas para una clase 
individual, la jerarquía de clases y las colaboraciones 
de clases poseen un valor incalculable, para el ingenie- 
ro del software que ha de evaluar la calidad del diseño. 
En capítulos anteriores se estudió que la clase encap- 
sula operaciones (procesamiento) y atributos (datos). 
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Así mismo, la clase «padre» es de las que heredan las 
subclases (algunas veces llamadas hijas), sus atributos 
y Operaciones. La clase, normalmente, colabora con 
otras clases. Cada una de estas características pueden 
usarse como base de la medición?, 


2 Nótese que la validez de algunas métricas, discutidas en este capí- 
tulo, actualmente se debate en la literatura técnica. Aquellos que 
abanderan la teoría de medición requieren de un grado de forma- 
lismo que algunas de las métricas OO no proporcionan. De cualquier 
manera, es razonable declarar que todas las métricas proporcionan 
una visión útil para el ingeniero de software. 
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24.4.1. La serie de métricas CK 


Uno de los conjuntos de métricas OO más ampliamen- 
te referenciados, ha sido el propuesto por Chidamber y 
Kemcrer [CH194]. Normalmente conocidas como la 
serie de métricas CK, los autores han propuesto seis 
métricas basadas en clases para sistemas OO?, 


Métodos ponderados por clase (MPC). Asumen 
que n métodos de complejidad C¡, €), ...C, se definen 
para la clase C, La métrica de complejidad específica 
que se eligió (por ejemplo, complejidad ciclomática) 
debe normalizarse de manera que la complejidad nomi- 
nal para un método toma un valor de 10. 


MPC = 2£c; 
para cada i = 1 hasta n. 


El número de métodos y su complejidad son indicado- 
res razonables de la cantidad de esfuerzo requerido para 
implementar y verificar una clase. En suma, cuanto 
mayor sea el número de métodos, más complejo es el 
árbol de herencia (todas las subclases heredan métodos 
de sus padres). Finalmente, a medida que crece el 
número de métodos para una clase dada, más probable 
es que se vuelvan más y más específicos de la aplica- 
ción, así que se limita el potencial de reutilización. Por 
todas estas razones, el MPC debe mantenerse tan bajo 
como sea razonable. 


j CLA VE 


E número de métodos y su complejidad está 
directamente relacionado con el esfuerzo requerido 
para comprobar una clase. 


Aunque podría parecer relativamente claro llevar la 
cuenta del número de métodos en una clase, el pro- 
blema es más complejo de lo que parece, Churcher 
y Shepperd [CHU95] discuten este aspecto cuando 
escriben: 


Para contar métodos, se debe contestar la pregunta funda- 
mental: «¿pertenece un método únicamente a la clase que lo 
define, o pertenece a cada clase que la hereda directa o indi- 
rectamente?». Las preguntas como esta pueden parecer trivia- 
les, ya que el sistema de ejecución las resolverá finalmente. De 
cualquier manera, las implicaciones para las métricas deben 
ser significativas. 


Una posibilidad es restringir el contador de la clase actual 
ignorando los miembros heredados. La motivación para esto 
podría ser que los miembros heredados ya han sido contados 
en las clases donde fueron definidos, así que el incremento de 
la clase es la mejor medida de su funcionalidad, lo que refleja 
su razón para existir. Para entender lo que la clase lleva a cabo, 
la fuente de información más importante son sus propias ope- 
raciones. Si una clase no puede responder a un mensaje (por 


3 Chidamber, Darcy y Kemerer usan el término métodos en vez de 
operaciones. Su utilización del término es reflejada en esta sección. 
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ejemplo, le falta un método correspondiente de sí), entonces 
pasará su mensaje a sus clases padres. 


En el otro extremo, el recuento podría incluir a todos aque- 
llos métodos definidos en la clase en cuestión, junto con los 
métodos heredados. Este enfoque enfatiza la importancia del 
espacio de estados, en lugar del incremento de la clase, para la 
comprensión de la clase. 


Entre estos extremos, existe cierto número de posibilidades 
diferentes. Por ejemplo, una podría restringir el recuento a la 
clase en cuestión y los miembros heredados directamente de 
sus padres. Este enfoque se basa en el argumento de que la 
especialización de clases padres es lo más directamente rele- 
vante en el comportamiento de las clases descendientes. 

Así como la mayoría de las convenciones de recuento 
en métricas de software, cualquiera de los enfoquesresu- 
midos con anterioridad es aceptable, siempre que el 
enfoque de recuento sea aplicado consistentemente al 
momento de recolectar métricas. 


Árbol de profundidad de herencia (APH). Esta 
métrica se define como «la máxima longitud del nodo 
a la raíz del árbol» [CH194]. Con referencia a la Figura 
24.1, el valor del APH para la jerarquía de clases mos- 
trada es de 4. 


A medida que el APH crece, es posible que clases de 
más bajos niveles heredarán muchos métodos. Esto con- 
lleva dificultades potenciales, cuando se intenta prede- 
cir el comportamiento de una clase. Una jerarquía de 
clases profunda (el APH es largo) también conduce a 
una complejidad de diseño mayor. Por el lado positivo, 
los valores APH grandes implican un gran número de 
métodos que se reutilizarán. 


Número de descendientes (NDD). Las subclases 
inmediatamente subordinadas a una clase en la jerar- 
quía de clases se denominan sus descendientes. Con 
referencia a la Figura 24.1, la clase C2 tiene tres des- 
cendientes —subclases C21,C22 y C23—., 


A medida que el número de descendientes crece, la 
reutilización se incrementa, pero además es cierto que 
cuando el NDD crece, la abstracción representada por 
la clase predecesora puede diluirse. Esto significa que 
existe una posibilidad de que algunos descendientes no 
sean miembros, realmente apropiados, de la clase pre- 
decesora. A medida que el NDD crece, la cantidad de 
pruebas (requeridas para ejercitar cada descendiente en 
su contexto operativo) se incrementará también. 


Cons 


la herencia es una habilidad extremadamentepoderasa, 
que puede meterlo en problemas, si no se usa ron 
cuidada. Utilice el APH y otros métricas relacionadas 
para darse una lectura de la complejidad de la jerarquía 
de clases. 
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FIGURA 24.1. Unajerarquía de clases. 


Acoplamiento entre clases objeto (ACO). El 
modelo CRC (Capítulo 21) debe utilizarse para deter- 
minar el valor de ACO. En esencia, ACO es el número 
de colaboraciones listadas para una clase, en la tarjeta 
índice CRC. 

A medida que ACO se incrementa, es más probable 
que el grado de reutilización de una clase decrezca. Valo- 
res altos de ACO además complican las modificaciones 
y las pruebas, que se producen cuando se realizan modi- 
ficaciones. En general, los valores de ACO para cada 
clase deben mantenerse tan bajos como sea razonable. 
Esto es consistente con la regla general para reducir el 
acoplamiento, para el software convencional. 


Cons 


los conceptosde acoplamiento y cohesiónse aplican tanto 
al software convencionalcomo ol 00. Mantenga 
el acoplamiento de clases bajo y la cohesiónde operación alto. 


Respuesta para una clase (RPC). El conjunto de 
respuesta de una clase es «una serie de métodos que 
pueden potencialmente ser ejecutados, en respuesta a 
un mensaje recibido por un objeto, en la clase» [CHI94]. 
RPC se define como el número de métodos en el con- 
junto de respuesta. 

A medida que la RPC aumenta, el esfuerzo requerido 
para la comprobación también se incrementa, ya que la 


% la definición formal es un poco más compleja. Véase [CHI94] para 
más detalle. 


secuenciade comprobación (Capítulo 23) se incrementa 
también. Así mismo, se dice que, así como la RPC 
aumenta, la complejidad del diseño global de la clase 
se incrementa. 


Carencia de cohesión en los métodos (CCM). Cada 
método dentro de una clase, C, accede a uno o más atri- 
butos (también llamados variables de instancia) CCM 
es el número de métodos que accede a uno o más de los 
mismos atributos”. Si no existen métodos que accedan 
a los mismos atributos, entonces CCM =0. 


Para ilustrar el caso en el que CCM es diferente de 0, 
considérese una clase con 6 métodos. Cuatro de los méto- 
dos tienen uno o más atributos en común (es decir, acce- 
den a atributos comunes). De esta manera, CCM =4. 


Si CCM es alto, los métodos deben acoplarse a otro, 
por medio de los atributos. Esto incrementa la comple- 
jidad del diseño de clases. En general, los valores altos 
para CCM implican que la clase debe diseñarse mejor 
descomponiendo en dos o más clases distintas. Aunque 
existan casos en los que un valor alto para CCM esjus- 
tificable, es deseable mantener la cohesión alta, es decir, 
mantener CCM bajo. 


rientodos o objetos, 
ol de la: tecnología de objetos 
ica de la ingeniería de software 


24.4.2. Métricas propuestas por Lorenz y Kidd 


En su libro sobre métricas OO, Lorenz y Kidd [LOR94] 
separan las métricas basadas en clases en cuatro amplias 
categorías: tamaño, herencia, valores internos y valores 
externos. Las métricas orientadas al tamaño para las cla- 
ses OO se centran en el recuento de atributos y operacio- 
nes para cada clase individual, y los valores promedio para 
el sistema0O como un todo. Las métricas basadas en la 
herencia se centranen la forma en que las operaciones se 
reutilizanen lajerarquía de clases. Las métricas para valo- 
res internos de clase examinan la cohesión (Sección 24.4.1) 
y los aspectos orientados al código; las métricas orienta- 
das a valores externos, examinan el acoplamientoy lareu- 
tilización. A continuación, una muestra de métricas 
propuestas por Lorenz y Kidd *: 


Tamano de clase (TC). El tamaño general de una clase 

puede medirse determinando las siguientes medidas: 

+. el total de operaciones (operaciones tanto heredadas 
como privadas de la instancia), que se encapsulan 
dentro de la clase. 

+. €lnúmero de atributos (atributos tanto heredados como 
privados de la instancia), encapsulados por la clase. 


$ Para un tratamiento más completo, véase [LOR94]. 
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Conse) 


Durante la revisión del modelo de ADO, las tarjetas CRC 
proporcionan una indicación razonable de las valores 
esperados paro TC. Si encuentra uno clase con demasiada 
responsobilidodaurante ADO, considere el particionarla. 


La métrica MPC propuesta por Chidamber y Keme- 
rer (Sección 24.4.1) es también una métrica ponderada 
del tamaño de clase. 


Como se indicó con anterioridad, valores grandes 
para TC indican que la clase debe tener bastante res- 
ponsabilidad. Esto reducirá la reutilización de la clase 
y complicará la implementación y las pruebas. En gene- 
ral, operaciones y atributos heredados o públicos deben 
ser ponderados con mayor importancia,cuando se deter- 
mina el tamaño de clase. [LOR94] Operaciones y atri- 
butos privados, permiten la especialización y son más 
propios del diseño. 


También se pueden calcular los promedios para el 
número de atributos y operaciones de clase. Cuanto 
menor sea el valor promedio para el tamaño, será más 
posible que las clases dentro del sistema puedan reuti- 
lizarse. 


Número de operaciones redefinidas para una sub- 
clase (NOR). Existen casos en que una subclase reem- 
plaza una operación heredada de su superclase por una 
versión especializada para su propio uso. A esto se le 
llama redefinición. Los valores grandes para el NOR, 
generalmente indican un problema de diseño. Tal como 
indican Lorenz y Kidd: 

Dado que una subclase debe ser la especialización de sus 
superclases, deben, sobre todo, extender los servicios (opera- 
ciones) de las superclases. Esto debe resultar en nuevos nom- 
bres de métodos únicos. 

Si el NOR es grande, el diseñador ha violado la abs- 
tracción representada por la superclase. Esto provoca 
una débil jerarquía de clases y un software OO, que 
puede ser difícil de probar y modificar. 


Número de operaciones añadidas por una sub- 
clase (NOA). Las subclases se especializan añadiendo 
operaciones y atributos privados. A medida que el 
valor NOA se incrementa, la subclase se aleja de la 
abstracción representada por la superclase. En gene- 
ral, a medida que la profundidad de la jerarquía de 
clases incrementa (APH se vuelve grande), el valor 
para NOA a niveles más bajos en la jerarquía debería 
disminuir. 

Índice de especialización (IES). El índice de espe- 
cialización proporciona una indicación aproximada del 
grado de especialización, para cada una de las subcla- 
ses en un sistema OO. La especialización se puede alcan- 
zar añadiendo o eliminando operaciones, pero también 
redefiniendo. 

IE = [NOR xnivel ]/M 


total 
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donde nivel corresponde al nivel en la jerarquía de cla- 
ses en que reside la clase, y M,,¡q, es el número total de 
métodos de la clase. Cuanto más elevado sea el valor 
de IE, más probable será que lajerarquía de clases tenga 
clases que no se ajusten a la abstracción de la super- 


clase. 


24.4.3. La colección de métricas MDOO 


Harrison, Counseil y Nithi [HAR98] propusieron un 
conjunto de métricas para el diseño orientado a objetos 
(MDOO), que proporcionan indicadores cuantitativos 
para el diseño de características OO. A continuación, 
una muestra de métricas MDOO: 


+00 para evalvar su calidad, 
coda vez, conforme 
crementóndose 


Factor de herencia de métodos (FHM). El grado 
en que la arquitectura de clases de un sistema OO hace 
uso de la herencia tanto para métodos (operaciones) 
como atributos, se define como: 


FHM = YE M¡C;)/ EM,(C;) 


donde el sumatorio va desde i=1 hasta TC. TC se defi- 
ne como el número total de clases en la arquitectura, C; 
es una clase dentro de la arquitectura, y 


M¿(C;) =M¿C;) +M¡C;) 
donde 


M¿(C;¡) =al número de métodos que pueden ser invo- 
cados en relación con C; 


MC) = al número de métodos declarados en la clase 
i 

M/(C;) =al número de métodos heredados (y no rede- 

finidos) en C; 

El valor de FHM (el factor de herencia de atributo, 


FHA, se define de manera análoga), proporciona una 
referencia sobre impacto de la herencia en software OO. 


Factor de acoplamiento (FA). Con anterioridad, en 
este capítulo se indicó que el acoplamiento es un indi- 
cador de las conexiones entre los elementos del diseño 
OO. La colección de métricas MDOO define el factor 
de acoplamiento de la siguiente manera: 


FA = [2,2 es_cliente (C;, C¡)] / (1 <TC) 


donde los sumatorios van desde ¡ = 1 hasta TC y desde 
J= 1hasta TC. La función 


Es cliente = 1, si existe una relación entre la clase 
cliente, C, y la clase servidora C, y (+ C,. 


Es_cliente = 0, en cualquier otro caso. 
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A pesar de que muchos factores afectan la compleji- 
dad, comprensión y mantenimiento del software, es razo- 
nable concluir que conforme el valor del FA crece, la 
complejidad del software OO también crece, y la com- 
prensión, el mantenimiento y el potencial de reutiliza- 
ción, pueden resentirse como resultado. 


Factor de polimorfismo (FP). Harrison, Counsell y 
Nithi [HAR98] definen FP como «el número de méto- 
dos que redefinen métodos heredados, dividida por el 
máximo número de posibles situaciones polimórficas 
distintas...; de esta manera, el FP es una medida indi- 
recta de la cantidad relativa de ligadura dinámica en un 
sistema». La colección de métricas MDOO define el FP 
de la siguiente manera: 


FP =2M,(C¡)/ 2, [M,(C;) xDC (C;)] 
donde los sumatorios van desde i= 1 hasta TC y 


M¿4C) =M,[C¡) + MAC) 


M,(C;) = al número de métodos nuevos. 

M.(C;) = al número de métodos redefinidos. 

DC(C;) = al número de descendientes (el número de 

clases descendientes de una clase base). 

Harrison, Counsell y Nithi [HAAR98] presentan un 
análisis detallado de FHM, FA y FP en conjunto con 
otras métricas, y examinan su validez de uso, en la eva- 
luación de la calidad del diseño. 


Ya que la clase es la unidad dominante en los siste- 
mas OO, se han propuesto menos métricas para ope- 
raciones que las relacionadas con las clases. Churcher 
y Shepperd [CHU9S] discuten lo anterior cuando 
declaran que: 

Resultados de estudios recientes indican que los métodos 
tienden a ser pequeños, tanto en términos de número de sen- 
tencias como en complejidad lógica [WIL93], sugiriendoque 
la estructura de conectividdd de un sistema debe ser mas impor- 
tante que el contenido de los módulos individuales. 

De cualquier modo, existen algunas ideas que pue- 
den llegar a apreciarse, examinando las características 
promedio para los métodos (operaciones). A continua- 
ción se resumen tres simples métricas, propuestas por 
Lorenz y Kidd [LOR94]: 


Tamaño medio de operación (TO, ¿q ¡p). Aunque 
las líneas de código podrían ser usadas como un indi- 
cador para el tamaño de operación, la medida LDC ado- 
lece de todos los problemas discutidos en el Capítulo 4. 
Por esta razón, el número de mensajes enviados por la 
operación proporciona una alternativa para el tamaño 
de operación. A medida que el número de mensajes 


enviados por una sola operación se incrementan, es más 
probable que las responsabilidades no hayan sido correc- 
tamente asignadas dentro de la clase. 


Los métricas pueden aplicarse a nivel de componentes, 
perotambién pueden oplicarse a operaciones. Véase el 
Capítulo 19 para más detalles. 


Complejidad de operación (CO). La complejidad 
de una operación puede ser calculada usando cualquiera 
de las métricas de complejidad (Capítulo 19) propues- 
tas para el software convencional [ZUS90]. Ya que las 
operaciones deben limitarse a una responsabilidad espe- 
cífica, el diseñador debería esforzarse por mantener la 
CO tan baja como sea posible. 


Número de parámetros de media por operación 
(NP media)» Tan largo como sea el número de paráme- 
tros de operación, más compleja será la colaboración 
entre objetos. En general, NP debe mantenersetan 
baja como sea posible. 


media 


Las métricas de diseño anotadas en las Secciones 24.4 
y 24.5 proporcionan una indicación de la calidad de 
diseño. También proveen una indicación general de la 
cantidad de esfuerzo de pruebas requerido para probar 
un sistema OO. 

Binder [BIN94] sugiere que una amplia gama de 
métricas de diseño tienen una influencia directa en la 
«comprobabilidad» de un sistema OO. Las métricas se 
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organizan en categorías, que reflejan características de 
diseño importantes. 


Encapsulación 


Carencia de cohesión en métodos (CCM)?. Cuanto 
más alto sea el valor CCM será necesario probar más 
estados para asegurar que los métodos no generan efec- 
tos colaterales. 


$ Véase la Sección 24.4.1 para una descripción de CCM 
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Porcentaje público y protegido (PPP). Los atri- 
butos públicos que se heredan de otras clases son visi- 
bles para esas clases. Los atributos protegidos son 
una especialización y son privados a subclases espe- 
cíficas. Esta métrica indica el porcentaje de atribu- 
tos de una clase que son públicos. Valores altos para 
PPP incrementan la probabilidad de efectos colate- 
rales entre clases. Las pruebas deben diseñarse para 
asegurar que ese tipo de efectos colaterales sean des- 
cubiertos. 


Acceso público a datos miembros (APD). Esta 
métrica indica el número de clases (o métodos) que 
pueden acceder a los atributos de otras clases, una 
violación de encapsulación. Valores altos para APD 
producen potencialmente efectos colaterales entre 
clases. Las pruebas deben diseñarse para estar segu- 
ros de que ese tipo de efectos colaterales serán des- 
cubiertos. 


Herencia 


Número de clases raíz (NCR). Esta métrica es un 
recuento de las distintasjerarquías de clases, que se des- 
criben en el modelo de diseño. Se deben desarrollar las 
colecciones de pruebas para cada clase raíz, y lajerar- 
quía de clases correspondiente. A medida que el NCR 
se incrementa, el esfuerzo de comprobación también se 
incrementa. 


EMAS ORIENTADOS A OBIETOS 


Cons: f) 


La comprobación DO pued ser un poco compleja. 

las métricas pueden ayudarle a laasignación de recursos 
de pruebas a hilos, escenarios y grupas de clases, 

queson «sujetos» basados en características ponderadas. 
Utilicelos. 


Número de Padres Directos (NPD). Cuando es uti- 
lizado en el contexto OO,el NPD es una indicación de 
herencia múltiple. NPD > 1 indica que la clase hereda 
sus atributos y operaciones de más de una clase raíz. Se 
debe evitar que NPD > 1 tanto como sea posible. 


Número de descendientes (NDD) y árbol de pro- 
fundidad de herencia (APH). Tal como se explicó en 
el Capítulo 23, los métodos de la superclase tendrán que 
ser probados nuevamente para cada subclase. 


Además de las métricas anteriores, Binder [BIN94] 
también define métricas para la complejidad y polimor- 
fismo de las clases. Las métricas definidas para la com- 
plejidad de clase, incluyen tres métricas CK (Sección 
24.4.1): Métodos ponderados por clase (MPC), el aco- 
plamiento entre clases de objetos (ACO) y la respuesta 
para una clase (RPC). En resumen, también se definen 
las métricas asociadas con el recuento de métodos. Las 
métricas asociadas con el polimorfismo se especifican en 
detalle. Lo mejor es dejar su descripción a Binder. 


Como se presentó en la Parte Dos de este libro, el tra- 
bajo del jefe de proyecto es planear, coordinar, registrar 
y controlar un proyecto de software. En el Capítulo 20 
se presentaron algunos de los aspectos especiales aso- 
ciados con la gestión de proyecto para proyectos OO. 
Pero ¿qué hay acerca de las métricas'? ¿Existen métri- 
cas OO especializadas que puedan ser utilizadas por el 
jefe de proyecto para proporcionar una visión interna 
adicional sobre el progreso de su proyecto? *, La res- 
puesta, desde luego es «sí». 

La primera actividad ejecutada por el jefe de pro- 
yecto es planificar, y una de las primeras tareas de pla- 
nificación es la estimación. Retomando el modelo 
evolutivo de procesos, la planificación se vuelve a revi- 
sar después de cada iteración del software. De este 
modo, la planificación (y sus estimaciones de proyec- 
to) es revisada nuevamente después de cada iteración 
de AOO, DOO e incluso POO. 

Uno de los aspectos clave, al que debe hacer frente 
un jefe de proyecto durante la planificación, es una esti- 


"Véase la Sección 24.4.1 para una descripción de NCC y APM 
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mación del tamaño de implementación del software. El 
tamaño es directamente proporcional al esfuerzo y la 
duración. Las siguientes métricas [LOR94] pueden pro- 
porcionar una visión sobre el tamaño del software: 


Referencia cruzada 


la oplicabilidad de un modelo de procesos evolutivos, 
llamado el modelo recursivo paralelo, se discute en el 
Capítulo 20. 


Número de escenario (NE). El número de escena- 
rios O casos uso (Capítulos 11 y 21) es directamente 
proporcional al número de clases requeridas para cubrir 
los requisitos, el número de estados para cada clase, el 
número de métodos, atributos y colaboraciones. El NE 
es un importante indicador del tamaño de un programa. 


Número de clases clave (NCC). Una clase clave se 
centra directamente en el dominio del negocio para el 
problema, y tendrá una menor probabilidad de serimple- 


8 Una descripción interesante de la colección de métricas CK (Sec- 
ción 24.4.1) para el uso en la administración de la toma de decisio- 
nes puede encontrarse en [CHI98]. 
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mentada por medio de la reutilización”, Por esta razón, 
valores altos para NCC indican gran trabajo de desa- 
rrollo substancial. Lorenz y Kidd [LOR94] sugieren que 
entre el 20 y el 40 por 100 de todas las clases en un sis- 
tema OO típico corresponde a las clases clave. El resto 
es infraestructura de soporte (GUL comunicaciones, 
bases de datos, etc.). 


Número de subsistemas (NSUB). El número de sub- 
sistemas proporciona una visión sobre la asignación de 
recursos, la planificación (con énfasis particular en el 
desarrollo paralelo) y el esfuerzo de integración global. 


Las métricas NE, NCC y NSUB pueden recolectar- 
se sobre proyectos VO pasados, y están relacionados con 
el esfuerzo invertido en el proyecto como un todo, y en 
actividades de procesos individuales (por ejemplo, AOO, 
DOO,POO y pruebas OO) Estos datos pueden también 
utilizarse junto con métricas de diseño discutidas con 
anterioridad en este capítulo, para calcular «métricas de 
productividad», tales como el número de clases prome- 
dio por desarrollador o promedio de métodos por per- 
sona/mes. Colectivamente, estas métricas pueden usarse 
para estimar el esfuerzo, duración, personal y otra infor- 
mación de proyecto para el proyecto actual. 


El software orientado a objetos es fundamentalmentedife- 
rente al software desarrolladocon el uso de métodos con- 
vencionales. Es por esto que las métricas para sistemas 
00 se enfocan en la ponderación que puede aplicarse a 
las clases y a las características del diseño —localiza- 
ción, encapsulación, ocultamiento de información, heren- 
cia y técnicas de abstracción de objetos —, que definen 
a la clase como única. 

La colección de métricas CK define seis métricas de 
software orientadas a la clase que se centran en la cla- 
se y en lajerarquía de clases. La colección de métricas 
también incorpora métricas para evaluar las colabora- 
ciones entre clases y la cohesión de métodos que resi- 
den dentro de la clase. Al nivel orientado a clases, la 
colección CK puede complementarse con las métricas 
propuestas por Lorenz y Kidd y la colección de métri- 
cas MDOO. Estas incluyen ponderaciones de «tamaño» 
de clase, y otras métricas que proporcionan una visión 
acerca del grado de especialización de las subclases. 


Las métricas orientadas a operaciones se centran 
en el tamaño y complejidad de las operaciones indi- 
viduales. Sin embargo, es importante hacer notar que 
la primera para las métricas de diseño OO es a nivel 
de clases. 

Se ha propuesto una amplia variedad de métricas OO 
para evaluarla comprobabilidad de un sistema OO. Estas 
métricas se centran en la encapsulación, herencia, com- 
plejidad de las clases y polimorfismo. Muchas de estas 
métricas han sido adaptadas de la colección CK y de las 
métricas propuestas por Lorenz y Kidd. Otras han sido 
propuestas por Binder. 

Las características ponderables del modelo de aná- 
lisis y diseño pueden ayudar al jefe de proyecto de un 
sistema OO en la planificación y registro de las acti- 
vidades. El número de escenarios (casos de uso), cla- 
ses clave y subsistemas proporcionan información 
acerca del nivel de esfuerzo requerido para implementar 
el sistema. 
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TEMAS ORIENTADOS A OBJETOS 


PROBLEMAS Y PUNTOS A CONSIDERAR 


24.1. Revise las métricas presentadas en este capítulo y en el 
Capítulo 19. ¿Cómo podía caracterizar las diferencias semán- 
ticas y sintácticas entre las métricas para software conven- 
cional y OO? 


24,2. ¿Cómo es que la localización afecta las métricas desa- 
rrolladas para software convencional y OO? 


24,3. ¿Por qué no se hace más énfasis en las métricas OO que 
abordan las característicasespecíficas de las operaciones resi- 
dentes dentro de una clase? 


24.4. Revise las métricas descritas en este capítulo y sugiera 
algunas que aborden directa o indirectamente el ocultamien- 
to de información. 


24.5. Revise las métricas descritas en este capítulo y sugiera 
algunas que aborden directa o indirectamente la abstracción. 


24.6. Una clase x posee 12 operaciones. Se ha calculado la 
complejidad ciclomática para todas las operaciones del siste- 
ma OO y el valor promedio de la complejidad del módulo es 
4, Para la clase x la complejidad de las operaciones de la 1a 
la 12es 5,4,3,6,8,2,2,5,5,4,4 respectivamente. Calcular MPC. 


24.7. Con respecto a las Figuras 20,8a y b, calcule el valor 
APH para cada uno de los árboles de herencia. ¿Cuál es el 
valor de NDD para la clase x2 de ambos árboles? 


24.8. Acuda a [CHI94] y presente una descripción de una pági- 
na referente a la definición formal de la métrica CCM. 


24.9. En la Figura 20.8b, ¿cuál es el valor de NOA para las 
clases x3 y x4? 


24.10.  Conrespecto a la Figura 20.8b suponga que las cua- 
tro operaciones han sido invalidadas en el árbol de herencia 
(¡jerarquía de clases), ¿cuál es el valor de IE para esajerarquía? 


24.11. Un equipo de software ha finalizado cinco proyec- 
tos hasta la fecha. Los datos siguientes han sidorecogidos para 
todos los tamaños de los proyectos: 


Número NGE NCC NSUB Esfuerzo 
de proyecto (días) 

1 34 60 3 900 

2 55 75 6 1.575 

3 122 260 8 4.420 

4 45 66 2 990 

5 80 124 6 2.480 


Se dispone de un nuevo proyecto que se encuentra 
en las primeras fases de AOO. Se estima que para este 
proyecto se desarrollarán 95 casos prácticos. Estimar: 
a. el número total de clases que serán necesarias para 

implementar el sistema; 

b. la cantidad total de esfuerzo que será necesaria para 

implementar el sistema. 

24.12. Su profesor le proporciona una lista de métricas OO 
procedente de este capítulo. Calcule los valores de estas métri- 
cas para uno o más de los problemas que se indican a conti- 
nuación: 

a. 
b. 


el modelo de diseño para el diseño HogarSeguro. 
el modelo de diseño para el sistema SSRB descrito 
en el problema 12.13. 

el modelo de diseño para el juego de vídeo conside- 
rado en el problema 22.14. 

el modelo de diseño para el correo electrónico con- 
siderado en el problema 22.15. 

el modelo de diseño para el problema CTA conside- 
rado en el problema 22.16. 


Una variedad de libros de AOO, DOO y Comprobación OO 
(véase Otras lecturas yfuentes de información en los Capítu- 
los 20, 21 y 22) que hacen referencia de paso a las métricas 
00, pero hay pocos que abordan el tema con detalle. Los libros 
escritos por Jacobson (Ohject-Oriented Software Engineering, 
Addison-Wesley, 1994) y Graham (Ohjecto-Oriented Met- 
hods, Addison-Wesley, segunda edición, 1993). Proporcionan 
un tratamiento más extenso que la mayoría. 

Whitmire [WHI97] presenta el tratamiento matemática y 
extensamente más sofisticado de las métricas OO publicadas 
a la fecha. Lorenz y Kidd [LOR94] y Hendersen-Sellers 
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(Object-Oriented Metrics: Measures of Complexity, Prentice- 
Hall, 1996) ofrecen los únicos libros dedicados a métricas 
OO. Otros libros dedicados a las métricas de software con- 
vencional (véase otras lecturas y fuentes de información en 
los Capítulos 4 y 19) contienen discusiones limitadas de 
métricas OO. 

Una amplia variedad de fuentes de información para métri- 
cas orientadas a objetos y temas relacionados se encuentra 
disponible en intemet. Una lista reciente de referencias a sitios 
(páginas) web relevantes a las métricas OO pueden encon- 
trarse en http://www. mhhe.pressman5.com 
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TEMAS AVANZADOS 
EN INGENIERÍA 
DEL SOFTWARE 


en consideración varios temas avanzados de la ingeniería del software 


E: esta parte de Ingeniería del Software: Un enfoque práctico se han tenido 


e que ayudarán a ampliar su entendimiento sobre la ingeniería del soft- 


ware. En los capítulos siguientes se abarcan las cuestiones siguientes: 


e. 


¿Qué notaciones y preliminares matemáticos («métodos formales»)se 
requieren para especificar formalmente el software? 


¿Cuáles son las actividades técnicas clave que se llevan a cabo durante el 
proceso de ingeniería del software de la sala limpia? 


¿Cómo se utiliza la ingeniería del software basada en componentes para 
crear sistemas a partir de componentes reutilizables? 


¿Cuál es el impacto de la arquitectura cliente/servidor sobre la forma en 
que se diseña el software de comercio electrónico? 


¿Se pueden aplicar los principios y conceptos de la ingeniería del software 
en productos y aplicaciones basadas en Web? 


¿Cuáles son las actividades técnicas clave que se requieren para la inge- 
niería del software? 


¿Cuáles son las opciones arquitectónicas para establecer un entorno de 
herramientas CASE? 


¿Cuál es el futuro de la ingeniería del software? 


Una vez que se hayan contestado estas preguntas, se comprenderán los temas 


que pueden tener un impacto profundo en la ingeniería del software la próxima 
década. : 
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CAPÍTULO 


5 MÉTODOS FORMALES 


OS métodos de la ingeniería del software se pueden desglosar sobre un espectro de «for- 

malidad», que va unido ligeramente al grado de rigor matemático que se aplica durante 

los métodos del análisis y diseño. Por esta razón, estos métodos, descritos anteriormente 
dentro de este libro, se colocarían en el extremo del espectro que corresponde a lo informal. 
Para crear modelos de análisis y diseño, se utiliza una combinación de diagramas, texto, tablas 
y notaciones sencillas, aplicando sin embargo poco rigor matemático. 

A continuación se considera el extremo opuesto del espectro de formalidad. Aquí se descri- 
be una especificación y un diseño utilizando una sintaxis y una semántica formal que especifi- 
can el funcionamiento y comportamiento del sistema. La especificación formal tiene una forma 
matemática (por ejemplo, se puede utilizar el cálculo de predicados como base para un lenguaje 
formal de especificación). 

En una introducción sobre métodos formales, Anthony Hall [HAL90] afirma lo siguiente: 


Los métodos formales son objeto de controversia. Quienes los propugnan afirman que pueden revolu- 
cionar el desarrollo [del software]. Sus detractores piensan que resultan imposiblemente difíciles. Mientras 
tanto, para la mayoría de la gente los métodos formales son tan poco familiares que resulta difícil juzgar 
estos puntos de vista contrapuestos. 


En este capítulo se exploran los métodos formales y se examina su posible impacto sobre-la 
ingeniería del software en los años venideros. 


VISTAZO RÁPIDO 


¿Qué es? Estos métodos permiten al inge- pueden perder vidas o incluso tener lee oescribe datos en un estado. Una 


niero del software crear una especifi- 
cación sinambigúedades que sea más 
completa y constante que las que se 
utilizan en los métodos convenciona- 
les u orientados a objetos. La teoría de 
conjuntos y las notaciones lógicas se 
utilizan para crear una sentencia cla- 
ra de hechos (o de requisitos). Esta 
especificación matemática entonces se 
puede analizar para comprobar que 
sea correcta y constante. Como esta 
especificación se crea utilizando nota- 
ciones matemáticas. inherentemente 
es menos ambigua que los nodos infor- 
males de presentación. 


¿Quién lo hace? Un ingeniero del soft- 


ware especializado crea una especifi- 
cación formal. 


¿Por qué esimportante? En sistemas 


críticos para la misión y para la segu- 
ridad, un fallo puede pagarse muy 
caro. Cuando la computadora falla se 


gravesconsecuencias económicas. En 
dichas situaciones es esencial descu- 
brir los errores antes de poner en ope- 
ración la computadora. Los métodos 
formales reducen drásticamente los 
errores de especificación, y conse- 
cuentemente son la base del software 
que tiene pocos errores una vez queel 
cliente comienza a utilizarlo. 


¿Cuéles son los pasos? El primer paso 


en la aplicación de los métodos for- 
males es definir el invariante de 
datos, el estado y las operaciones 
para el funcionamiento de un sistema. 
El invariante de datos es una condi- 
ción que se verifica mediante la eje- 
cución de una función que contiene un 
conjunto de datos. Los datos almace- 
nados forman el estadoen donde una 
función puede acceder y alterar; y las 
Operaciones son las acciones que tie- 
nen lugar en un sistema a medida que 
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operación se asocia a dos condicio- 
nes: una precondición y una postcon- 
dición. La notación y la heurística 
asociados con los conjuntos y especi- 
ficaciones constructivas ——operadores 
de conjuntos, operadores lógicos y 
sucesiones — forman la base de los 
métodos formales. 


¿Cuál es el producto obtenido? 


Cuando se aplican métodos formales 
se produce una especificación repre- 
sentada en un lenguaje formal comoZ 
Oo VDM. 


¿Cómo puedo estar seguro de que 


lo he hecho corredamente? Debi- 
do a que los métodos formales utilizan 
la matemática discreta como meca- 
nismo de especificación, para demos- 
trar que una especificación es correcta, 
se pueden aplicar pruebas lógicas a 
cada función del sistema. 
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La Encyclopedia of Software Engineering [MAR94] 
define los métodos formales de la siguiente forma: 


Los métodos formales que se utilizan para desarrollar sis- 
temas de computadoras son técnicas de base matemática para 
describir las propiedades del sistema. Estos métodos formales 
proporcionan marcos de referencia en el seno de los cuales las 
personas pueden especificar, desarrollar y verificar los siste- 
mas de manera sistemática, en lugar de hacerlo ad hoc. 


Se dice que un método es formal si posee una base mate- 
mática estable, que normalmente vendrá dada por un lengua- 
je formal de especificación. Esta base proporciona una forma 
de definir de manera precisa nociones tales como la consis- 
tencia y completitud, y, lo que es aun más relevante, la especi- 
ficación, la implementación y la corrección. 


ejorar la claridad y la precisión de los 
aciones de los requisitos y a la hora de 
frar tanto errores importantes como sutiles. 
Steve Eosterbrook et al. 


Las propiedades deseadas de una especificación for- 
mal - carencia de ambigiiedad, consistencia y com- 
pletitud— son los objetivos de todos los métodos de 
especificación. Sin embargo, la utilización de métodos 
formales da lugar a una probabilidad mucho mayor de 
alcanzar estos objetivos ideales. La sintaxis formal de 
un lenguaje de especificación (Sección 25.4) hace posi- 
ble interpretar los requisitos o el diseño de una forma 
única, eliminando esa ambigiledad que suele producir- 
se cuando es cualquier lector quien interpreta un len- 
guaje natural (por ejemplo, el español), o una notación 
gráfica. Las capacidades descriptivasde la teoría de con- 
juntos y de la notación gráfica (Sección 25.2) hacen 
posible un enunciado claro de los hechos (los requisi- 
tos). Para que los hechos sean consistentes puestos de 
manifiesto en un lugar de una especificación, no debe- 
rán verse contradichos al establecerse en otro lugar de 
la misma. La consistencia se asegura mediante una 
demostración matemática de que los hechos iniciales se 
pueden hacer corresponder formalmente (mediante 
reglas de inferencia) con sentencias posteriores exis- 
tentes dentro de la especificación. 

La completitud es difícil de lograr, aun cuando se uti- 
licen métodos formales. Cuando se está creando la espe- 
cificación se pueden dejar sin definir algunos aspectos 
del sistema; quizás otras características se omitan a pro- 
pósito para ofrecer a los diseñadores una cierta libertad 
a la hora de seleccionar un enfoque de implementación; 
además es imposible considerar todos los escenarios 
operacionales en un sistema grande y complejo. Por últi- 
mo, las cosas pueden omitirse simplemente por error. 

Aunque el formalismo proporcionado por las mate- 
máticas tiene un cierto atractivo para algunos ingenie- 
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ros del software, hay otros (hay quien diría que la mayo- 
ría) que no consideran especialmente agradable el pun- 
to de vista matemático del desarrollo del software. Para 
entender por qué un enfoque formal tiene un cierto inte- 
rés, es preciso considerar en primer lugar las deficien- 
cias asociadas a los enfoques menos formales. 


25.1.1. Deficiencias de los enfoques menos 
formales 


Los métodos descritos para el análisis y diseño en las 
Partes Tercera y Cuarta de este libro hacen un amplio 
uso del lenguaje natural y de toda una gama de nota- 
ciones gráficas. Aun cuando la aplicación cuidadosa de 
íos métodos de análisis y diseñojunto con una revisión 
detallada puede ciertamente llevar a un software de ele- 
vada calidad, la torpeza en la aplicación de estos méto- 
dos puede crear toda una gama de problemas. La 
especificación de un sistema puede contener contradic- 
ciones, ambigiiedades, vaguedades, sentencias incom- 
pletas y niveles mezclados de abstracción. 


CionsoH 


Aunque un buen índice de documentono puede eliminar 
las Contradicciones, puede ayudar a descubrirlas. 

Poro las especificaciones y otros documentoshay 

que invertir tiempo en crear un índice completo. 


Las contradicciones son conjuntos de sentenciasque 
difieren entre sí. Por ejemplo, una parte de la especifi- 
cación de un sistema puede afirmar que el sistema debe 
de monitorizar todas las temperaturas de un reactor quí- 
mico mientras que otra parte, que quizás haya escrito 
otro miembro del personal, puede afirmar que solamente 
será preciso monitorizar las temperaturas que perte- 
nezcan a un determinado intervalo. Normalmente, las 
contradicciones que se producen en la misma página de 
la especificación del sistema se pueden detectarcon faci- 
lidad. Sin embargo, es frecuente que las contradiccio- 
nes estén separadas por un elevado número de páginas. 

Las ambigúedades son sentencias que se pueden 
interpretar de muchas maneras. Por ejemplo, el enun- 
ciado siguiente es ambiguo: 

El operador de identidad consta del nombre y la contra- 
seña del operador; la contraseña consta de seis dígitos; debe 
de ser visualizada en la pantalla de seguridad, y se deposi- 
tará en el archivo de registro cuando el operador se conecte 
con el sistema. 


En este extracto, ¿La palabra «debe» alude a la con- 
traseña o a la identidad del operador? 


s humono, y volver a cometerlos 
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La vaguedad suele producirse porque la especifica- 
ción del sistema es un documento muy voluminoso. 
Alcanzar un elevado nivel de precisión de forma con- 
sistente es una tarea casi imposible. Puede dar lugar a 
sentencias tales como «la interfaz con el sistemaemplea- 
da por los operadores del radar debe ser amistosa para 
con el usuario», O «la interfaz virtual se basará en sim- 
ples conceptos globales que sean sencillos de entender 
y utilizar, y, además, en escaso número». Una revisión 
poco detallada de estas afirmaciones podría no detectar 
la carencia de información útil subyacente. 

La incomplección' es posiblemente uno de los pro- 
blemas que se producen más frecuentemente en las espe- 
cificaciones de sistemas. Por ejemplo, considérese el 
siguiente requisito funcional: 

El sistema debe de mantener el nivel horario del depósito a 
partir de los sensores de profundidad situados en el depósito. 
Estos valores deben de ser almacenados para los Ultimos seis 
meses. 

Esto describe la parte principal del almacenamiento 
del sistema. Supongamosque una de las Órdenes del sis- 
tema es: 

La función de la orden PROMEDIO tiene que visualizaren 
un PC el nivel medio de agua para un sensor concreto entre dos 
fechas dadas. 

Suponiendo que no se ofreciese más información 
acerca de esta orden, los detalles de la orden estarían 
gravemente incompletos. Por ejemplo, la descripción 
de la orden no incluye lo que sucedería si un usuario de 
sistema especificase una fecha que distase más de seis 
meses de la fecha actual. 

La mezcla de los niveles de abstracción se produce 
cuando sentencias abstractas se entremezclan aleato- 
riamente con sentencias que se encuentran en un nivel 
muy inferior. Por ejemplo, sentencias tales como: 


El objetivo del sistemaes hacer un seguimientode stock de 
un almacén 


pueden verse mezcladas con la siguiente: 


Cuando el encargado de la carga escribe la orden retirar 
será preciso comunicar el número de pedido, la identidad del 
artículo a retirar y la cantidad retirada. El sistema responderá 
con una confirmación de que la extracción es admisible. 


Aun cuando dichas sentencias son importantes en la 
especificación de un sistema, quienes hacen la especi- 
ficación suelen arreglárselas para mezclarlas de tal modo 
que resulta muy difícil ver toda la arquitectura funcio- 
nal global del sistema. 

Todos estos problema son más frecuentes que lo que 
uno desearía creer. Y cada uno de ellos representa una 
deficiencia potencial en los métodos convencionales y 
orientados a objetos de especificación. 


1 Esta muy extentida la traducción del término incompleteness por 
incompletitud, pero este término en español no está aceptado por la 
RAE. (N. del Trad.) 
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25.1.2. Matemáticas en el desarrollo del software 


Las matemáticas poseen muchas propiedades útiles para 
quienes desarrollan grandes sistemas. Una de las pro- 
piedades más útiles es que pueden describir de forma 
sucinta y exacta una situación física, un objeto o el resul- 
tado de una acción. La situación ideal sería que un inge- 
niero del software estuviera en la misma situación que 
un matemático dedicado a la matemática aplicada. Se 
debería presentar una especificación matemática de un 
sistema, y elaborar la solución en base a una arquitec- 
tura de software que implemente la especificación”. 

Otra de las ventajas de la utilización de las matemá- 
ticas en el proceso del software es que proporcionan una 
transición suave entre las actividades de ingeniería del 
software. En matemáticas no solo se pueden expresar 
especificaciones funcionales sino también diseños de sis- 
tema, y, desde luego, el código del programa es una nota- 
ción matemática, aunque ciertamente sea algo verbosa. 

La propiedad fundamental de las matemáticas es que 
admite la abstracción y es un medio excelente para el 
modelado. Dado que es un medio exacto, hay pocas 
probabilidades de ambigijedad, y las especificaciones 
se pueden verificar matemáticamente para descubrir 
contradicciones e incompletitud; y, por último, la vague- 
dad desaparece completamente. Además, las matemá- 
ticas se pueden utilizar para representar niveles de 
abstracción en la especificación de sistema de forma 
organizada. 

Las matemáticas constituyen una herramienta ideal 
para el modelado. Hacen posible exhibir el esquema 
fundamental de la especificación y ayudan al analista y 
especificador del sistema a verificar una especificación 
para su funcionalidad, sin problemas tales como el tiem- 
po de respuesta, las directrices de diseño, las directri- 
ces de implementación y las restricciones del proyecto 
que siempre estorban. También ayuda al diseñador, por- 
que la especificación de diseño del sistema muestra las 
propiedades del modelo, y ofrece tan sólo los detalles 
suficientes para hacer posible llevar a cabo la tarea que 
tengamos entre manos. 

Por último, las matemáticas proporcionan un eleva- 
do nivel de verificación cuando son usadas como medio 
de desarrollo del software. Cuando es preciso demos- 
trar que un diseño se ajusta a una especificación y que 
algunos códigos de programa son el reflejo exacto de 
un diseño, es posible utilizar una demostración mate- 
mática. Actualmente es la práctica preferida porque no 
hay que hacer un gran esfuerzo para la validación ini- 
cial, y porque gran parte de la comprobación del siste- 
ma de software tiene lugar durante la prueba de 
aceptación y del sistema. 


2 Una palabra de precaución es apropiada en este punto. Las espe- 
cificaciones matemáticas de sistemas que se presentan en este capí- 
tulo no son tan sucintas como una expresión matemática simple. Los 
sistemas de software son notoriamente complejos,y no sería realista 
esperar que pudieran especificarse en la misma línea que las mate- 
máticas. 
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25.1.3. Conceptos de los métodos formales 


El objetivo de esta sección es presentar los conceptos 
fundamentales implicados en la especificación mate- 
mática de sistema de software, sin abrumar al lector con 
un excesivo nivel de detalle matemático. Para lograr 
esto, se utilizarán unos pocos ejemplos sencillos: 


Ejemplo 1. Una tabla de símbolos. Para mantener 
una tabla de símbolos se utiliza un programa. Esta tabla 
se utiliza frecuentemente en muchos tipos distintos de 
aplicaciones. Consta de una colección de elementos sin 
duplicación. En la Figura 25.1 se muestra un ejemplo 
de tabla típica de símbolos en donde se representa una 
tabla que utiliza un sistema operativo para que contie- 
ne almacenados los nombres de los usuarios de un sis- 
tema. Otros ejemplos de tablas incluirían por ejemplo 
la colección de nombres del personal en un sistema de 
nómina, la colección de nombres de computadoras en 
un sistema de comunicaciones de red y la colección de 
destinos de un sistema que elabora horarios de trenes. 

Suponga que la tabla presentada en este ejemplo no 
consta de más de Maxlds miembros de personal. Esta 
afirmación, que impone una restricción sobre la tabla, es 
un componente de una condición conocida como inva- 
riante de datos —-ana idea importante a la cual volve- 
remos en repetidas ocasiones a lo largo del capítulo—. 


O 
Em VE 


Un invariante de datos es un conjunto de condicionesque 
son verdaderas durante la ejecución del sistema que 
contiene una colección de datos. 


Un invariante de datos es una condición verdadera 
a lo largo de la ejecución del sistema que contiene una 
colección de datos. El invariante de datos, que es váli- 
do para la tabla de símbolos descrita anteriormente, 
posee dos componentes: (1) que la tabla no contendrá 
más de Maxlds nombres y (2 Jque no existirán nombres 
duplicadosen la tabla. En el caso del programa de tablas 
de símbolos descrito anteriormente, esto significa que, 
independientemente del momento en que se examine la 
tabla de símbolos durante la ejecución del sistema, siem- 
pre contendrá un máximo de Maxlds identificadores de 
personal y no contendrá duplicados. 


e 
CLA VE 


En los métodos formales, un «estado» es un conjunto 
de datos almacenados a los que el sistema accede 

y modifica. Una «operación» es una acción que lee 

o escribe datos en un estado. 
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Maxlds= 10 


FIGURA 25.1. Una tabla de símbolos que se emplea 
para un sistema operativo. 


Otro concepto importante es el de estado. En el con- 
texto de métodos formales”, un estado es el dato alma- 
cenado al cual accede el sistema y que es alterado por 
éste. En el ejemplo del programa de la tabla de símbo- 
los, el estado es la tabla de símbolos. 

El concepto final es el de operación. Se trata de una 
acción que tiene lugar en un sistema y que lee o escri- 
be datos en un estado. Si el programa de tabla de sím- 
bolos se ocupa de añadir y eliminarnombres de personal 
de la tabla de símbolos, entonces estará asociado a dos 
Operaciones: una operación para añadir un nombre espe- 
cificado en la tabla de símbolos, y otra operación para 
eliminar un nombre existente de la tabla. Si el progra- 
ma proporciona la capacidad de comprobar si existe o 
no un nombre concreto en la tabla, quiere decir que será 
necesaria una operación que proporcione alguna indi- 
cación de la existencia del nombre en la tabla. 


$] 
a 


CLAVE 


la «precondición» define las circunstancias en los que una 
operación en particular es vólida. | a «postcondición» define 
que ocurre cuando una operación ha finalizado su acción. 


Una operación está asociada a dos condiciones: las 
precondiciones y las postcondiciones. Una precondi- 
ción define las circunstancias en que una operación en 
particular es válida. Por ejemplo, la precondición para 
una Operación que añada un nombre a la tabla de sím- 
bolos de identificadores de personal es válida sólo si el 
nombre que hay que añadir no está almacenado en la 
tabla y existen menos de Maxlds identificadores de per- 
sonal en la tabla. La postcondición de una operación 
define lo que ocurre cuando la operación ha finalizado 


3 Recuérdese que el término estado se ha utilizado también en los 
Capítulos 12 y 21 como una representación del comportamiento de 
un sistema o de objetos. 
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su acción. Esto se define mediante su efecto sobre el 
estado. En el ejemplo de la operación que añade un iden- 
tificador a la tabla de símbolos de identificadoresde per- 
sonal, la postcondición especificaría matemáticamente 
que la tabla habrá sido incrementada con el identifica- 
dor nuevo. 


Ejemplo 2. Un gestor de bloques. Una de las par- 
tes más importantes de los sistemas operativoses el sub- 
sistema que mantiene archivos que hayan sido creados 
por usuarios. Una parte del subsistema de archivos es 
el gestor de bloques. Los archivos del almacén de archi- 
vos están formados por bloques de espacio que se alma- 
cenan en algún dispositivo de almacenamiento de 
archivos. Durante el funcionamiento de la computadora, 
los archivos van siendo creados y borrados, lo cual 
requiere la adquisición y liberación de bloques de alma- 
cenamiento. Para abordar este bloque, el subsistema de 
archivo mantendrá una reserva de bloques libres y 
seguirá también la pista de aquellos bloques que se estén 
utilizando en ese momento. Cuando se liberen bloques 
procedentes de un archivo borrado lo normal será aña- 
dirlos a una cola de bloques que están a la espera de ser 
añadidos al depósito de bloques que no se utilizan. En 
la Figura 25.2 se muestra un cierto número de compo- 
nentes: la reserva de bloques no utilizados, los bloques 
que en la actualidad forman parte de los archivos admi- 
nistrados por el sistema operativo y aquellos bloques 
que estén esperando para ser añadidos a la reserva de 
espacio. Los bloques que están a la espera se mantie- 
nen en una cola y cada elemento de la cola contiene un 
conjunto de bloques procedentes de algún archivo 


borrado. 
Cionseof) 


lo técnico de Tormentodk ideas (Brainstorming) 
puede funcionar bien cuando se necesita desarrollar 
un invariante de datos poro uno función 
rozonoblementecomplejo. 


Para este subsistema,el estado es la colección de blo- 
ques libres, la colección de bloques usados y la cola de 
bloques devueltos. El invariante de datos, expresado en 
lenguaje natural, es: 


No habrá ningún bloque que esté a la vez usado y sin 
usar. 

Todos los conjuntos de bloques almacenados en la 
cola serán subconjuntos de la colección de bloques 
utilizados en ese momento. 

No existirán elementos de la cola que contengan los 
mismos números de bloque. 

La colección de bloques usados y bloques sin usar 
será la colección total de bloques de que consten los 
archivos. 

En la colección de bloques sin usar no existirán 
números de bloques duplicados. 
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Bloques sin usar 


Bloques usados 


25781011 12 


Se liberan 
los bloques 
después 
de borrar 
un artículo 


Archivo n.* 3 


Cola de bloques que contiene bloques de archivos borrados 


FIGURA 25.2. Un gestor de bloques. 


En cola para pasar a bloques sin usar 


Archivo n.? 2 


Archivo n.? 1 


En la colección de bloques usados no existirán núme- 
ros de bloques duplicados. 


Entre las operaciones asociadas a este subsistema se 
encuentran las siguientes: 


+. Una operación que añade una colección de bloques 
usados al final de la cola. 

Una operación que elimina una colección de bloques 
usados de la parte anterior de la cola y los coloca en 
la colección de bloques sin usar. 

Una operación que comprueba si la cola de bloques 


está o no vacía. 


La precondición de la primera operación es que los 
bloques que se vayan a añadir deben de encontrarseen la 
colección de bloques usados. La postcondición es que 
la colección de bloques debe de añadirse al final de la cola. 

La precondición de la segunda operación es que la 
cola debe de tener al menos un elemento. La postcon- 
dición es que los bloques deben de añadirse a la colec- 
ción de bloques sin usar. 

La operación final -comprobar si la cola de bloques 
proporcionados está o no vacía — no posee precondi- 
ción. Esto significa que la operación siempre está defi- 
nida, independientemente del valor que tenga el estado. 
Si la cola está vacía, la postcondición manda un valor 
verdadero, y falso si no lo está. 


Ejemplo 3. Un concentrador de impresión. En los 
sistemas operativos multitarea, existe un cierto número 
de tareas que hacen solicitudes para imprimir archivos. 
Con frecuencia, no se dispone de un número suficiente 
de dispositivos de impresión para satisfacer simultáne- 
amente todas las solicitudes de impresión en curso. Toda 
solicitud de impresión que no se pueda satisfacer de 
forma inmediata se ubicará en una cola a la espera de 
su impresión. La parte del sistema operativo que abarca 
la administración de estas colas se conoce con el nom- 
bre de concentrador de impresión. 

En este ejemplo se supone que el sistema operati- 
vo no puede emplear más de DispMax dispositivos de 
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salida y que cada uno tiene asociada una cola. Tam- 
bién se supondrá que cada uno de los dispositivos 
está asociado a un cierto límite de líneas por archi- 
vo que se pueden imprimir. Por ejemplo, un dispo- 
sitivo de salida que tenga un límite de 1.000 líneas 
de impresión estará asociado a una cola que conten- 
ga tan solo aquellos archivos que no posean más de 
1.000 líneas de texto. Los concentradores de impre- 
sión suelen imponer esta limitación para evitar las 
grandes tareas de impresión, que podrían ocupar unos 
dispositivos de impresión lentos durante períodos de 
tiempo sumamente largos. En la Figura 25.3 se mues- 
tra una representación esquemática de un concen- 
trador de impresión. 


Según se muestra en la figura, el estado del concen- 
trador consta de cuatro componentes: las colas de archi- 
vos que esperan para ser impresos, en donde cada cola 
está asociada a un dispositivo de salida en particular; la 
colección de dispositivos controlados por el concentra- 
dor; la relación entre dispositivos de salida y el tamaño 
máximo de archivo que puede imprimir cada uno de 
ellos, y, por último, la relación entre los archivos que 
esperan para ser impresos y su tamaño en líneas. Por 
ejemplo, en la Figura 25.3 se muestra el dispositivo de 
salida LP1, que con un límite de impresión de 750 líneas, 
tiene dos archivos fimp y personas a la espera de impri- 
mirse, y con un tamaño de 6530 líneas y 700 líneas res- 
pectivamente. 


Colas 


personas 


Dispositivos de salida 


límites Dimensiones 
¡AE 
LP1— 750 datos nuevos —=> 450 
LP2 > 500 fimp —=650 
LAS? -mmmtn 300 exres —»50 
LAS2 200 personas —> 700 


FIGURA 25.3. Un concentrador de impresión. 


El estado del concentrador se representa mediante 
los cuatro componentes: colas, dispositivos de salida, 
límites y dimensiones. El invariante de datos tiene cin- 
co componentes: 


Cada dispositivo de salida está asociado a un límite 
superior de líneas de impresión. 

Todo dispositivo de salida está asociado a una cola 
de archivos esperando impresión, que posiblemente 
no está vacía. 
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Todo archivo tiene asociado un tamaño. 

Toda cola asociada a un dispositivo de salida con- 
tendrá archivos que tengan un tamaño menor que el 
límite superior de este dispositivo de salida. 

No existirán más de DispMax dispositivos de salida 
que sean administrados por este concentrador. 


LUN 
a 
ELA VE 


los estados y las operaciones en muchos aspectos 

son análogos a la definición de clases en los sistemas 
orientados a objetos. los estados representan el dominio 
de los datos (atributos) y los operaciones 

son los procesos (métodos) que manipulan los datos. 


El concentrador puede tener asociado un cierto núme- 
ro de operaciones. Por ejemplo: 


Una operación que añada un dispositivo de salida 
nuevo al concentrador, junto con su límite de impre- 
sión asociado. 

Una operación que elimina un archivo de la cola aso- 
ciada a un determinado dispositivo de salida. 

Una operación que añada un archivo a la cola aso- 
ciada a un dispositivo de salida en particular. 

Una operación que altere el límite superior de líneas 
de impresión para un dispositivo de salida en par- 
ticular. 

Una operación que traslade un archivo de una cola 
asociada a un dispositivo de salida a otra cola aso- 
ciada a un segundo dispositivo de salida. 


Cada una de estas operaciones se corresponde con 
una función del concentrador. Por ejemplo, la primera 
Operación se correspondería con la notificación al con- 
centrador de un nuevo dispositivo conectado al orde- 
nador que contiene el sistema operativo que a su vez 
administra al concentrador. 

Tal como sucedía antes, cada operación está asocia- 
da a una precondición y a una postcondición. Por ejem- 
plo, la precondición para la primera operación es que el 
nombre del dispositivode salida ya no existe y que exis- 
tan en ese momento menos de DispMax dispositivos de 
salida a efectos del concentrador. La postcondición es 
que el nombre del dispositivo nuevo se añade a la colec- 
ción de nombres de dispositivos ya existentes, formán- 
dose una nueva entrada para el dispositivo sin que esta 
entrada tenga asociados archivos en su cola, y el dis- 
positivo se asocia a su límite de impresión. 

La precondición de la segunda operación (la elimina- 
ción de un archivo de una cola asociada a un determina- 
do dispositivode salida) es que el dispositivo sea conocido 
para el concentrador y que exista al menos una entrada 
en la cola asociada al dispositivo. La postcondición es 
que la cabeza de la cola asociada al dispositivode salida 
sea eliminada y se borre su entrada en la parte del con- 
centrador que siga la pista de los tamaños de archivos. 
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La precondición de la quinta operación descrita ante- 
riormente (el traslado de un archivo de una cola aso- 
ciada a un dispositivo de salida a la cola asociada a un 
segundo dispositivo de salida) es: 


» El primer dispositivo de salida es conocido para el 
concentrador. 

+ El segundo dispositivo de salida es conocido para el 

concentrador. 

La cola asociada al primer dispositivo contiene el 

archivo que hay que trasladar. 
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El tamaño del archivo es menor o igual que el límite 
de impresión asociado al segundo dispositivode salida. 


La postcondición es que el archivo será eliminado 
de una cola y añadido a otra cola. 

En cada uno de los ejemplos indicados en esta sec- 
ción, se han presentado los conceptos clave de la espe- 
cificación formal. Se ha hecho esto sin hacer hincapié 
en las matemáticas necesarias para hacer formal la espe- 
cificación. Consideraremos estas matemáticas en la sec- 
ción siguiente. 


Para aplicar de forma eficiente los métodos formales, 
el ingeniero del software debe de tener un conocimien- 
to razonable de la notación matemática asociada a los 
conjuntos y a las sucesiones, y a la notación lógica que 
se emplea en el cálculo de predicados. El objetivo de 
esta sección es proporcionar una breve introducción al 
tema. Para una descripción más detallada del tema se 


recomienda examinar los libros especializados en esta 
materia: por ejemplo, [WIL87], [GRI93] y [ROS95]. 


25.2.1. Conjuntos y especificación constructiva 


Un conjunto es una colección de objetos o elementos que 
se utiliza como la piedra angular de los métodos forma- 
les. Los elementos de un conjunto son únicos (es decir, 
no se permiten los duplicados). Forman un grupo peque- 
ño de elementos dentro de llaves, separando mediante 
comas sus elementos. Por ejemplo, el conjunto 


[C++, Pascal, Ada, Cobol, Java] 


contiene los nombres de cinco lenguajes de programa- 
ción. 

El orden en que aparecen los elementos dentro de un 
conjunto no es relevante. El número de elementos del 
conjunto se conoce con el nombre de cardinalidad. El 
operador + proporciona la cardinalidad de un conjunto. 
Por ejemplo, la expresión 


F(A,B,C,D) =4 
indica que se ha aplicado el operador de cardinalidad al 


conjunto mostrado, con un resultado que indica el núme- 
ro de elementos que había en el conjunto. 


¿Qué es una especificación 
constructiva de conjuntos? 


Hay dos maneras de definir un conjunto. En primer 
lugar, se puede definir por enumeración de sus elemen- 
tos (esta es la forma en que se han definido los conjun- 
tos indicados anteriormente). El segundo método 
consiste en crear una especificación constructiva de con- 
juntos. La forma general de los números de un conjun- 
to se especifican empleando una expresión Booleana. 
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Las especificaciones constructivas de conjuntos resul- 
tan preferibles a las especificaciones enumeradas, por- 
que hacen posible definir de forma sucinta los conjuntos 
formados por muchos miembros. También se define 
explícitamente la regla que se utiliza para construir el 
conjunto. 

Considere el siguiente ejemplo de especificación 
constructiva: 


ln: Nin<3-.n], 


Esta especificación posee tres componentes: una sig- 
natura, n ; N ,un predicado n < 3; y un término, n. La 
signatura especifica el intervalo de valores que se con- 
siderará cuando se forme el conjunto, el predicado (una 
expresión Booleana) define la forma en que se debe de 
construir el conjunto y, por último, el término ofrece la 
forma general del elemento del conjunto. En el ejem- 
plo anterior, N denota el conjunto de los números natu- 
rales; por tanto, es preciso considerar los números 
naturales, el predicado indica que solamente tienen que 
incluir los números naturales menores que 3, y el tér- 
mino especifica que todos los elementos del conjunto 
será de la forma n. Por tanto, la especificación anterior 
define un conjunto: 


(0, 1, 2] 


Cuando la forma de los elementos del conjunto es 
evidente, se puede omitir el término. Por ejemplo, el 
conjunto anterior se podría especificar en la forma: 


[n: N|ln<3) 


Los conjuntos que se han descrito anteriormente 
poseían todos ellos elementos que tienen objetos indi- 
viduales. También se pueden construir conjuntos for- 
mados a partir de elementos que sean pares, ternas, etc. 
Por ejemplo, la especificación de conjunto 


lx y : N[x+y=10-+(x, y) l 
define el conjunto de parejas de números naturales con 


la forma (x, y?) y en los cuales la suma de x e y es 10. 
Se trata del conjunto 


(1, 81), Q, 64), (3, 49),...) 
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Evidentemente, una especificación constructiva de 
conjuntos tal como la que se requiere para representar 
algunos componentes del software de computadoras 
puede ser considerablemente más complicada que los 
indicados anteriormente. Sin embargo, la misma forma 
y la estructura básica seguirán siendo las mismas. 


25.2.2. Operadores de conjuntos 

Para representar las operaciones conjuntos y las opera- 
ciones lógicas se utiliza el mismo conjunto especiali- 
zado de símbolos. El ingeniero del software que pretenda 
aplicar los métodos formales debe de entender estos 
símbolos. 


Consiof) 


Cuando se desarrollan especificaciones formales 

és indispensable el conocimientodel conjunto 

de operaciones. Si se pretende aplicar métodos formales 
lo mejor es dedicar tiempo poro fomiliarizamos 

con los conjuntos de operaciones. 


El operador E se utiliza para indicar la pertenencia 
de un conjunto. Por ejemplo la expresión 


XEX 


tiene el valor verdadero si x es miembro del conjunto X 
y el valor falso en caso contrario. Por ejemplo, el pre- 
dicado 


12€ (6,1,12,22) 


tiene el valor verdadero por cuanto 12 es un miembro 
del conjunto. 

El contrario del operador E es el operador £. La 
expresión 


xe£X 


posee el valor verdadero si x no es miembro de conjunto 

X yfalso en caso contrario. Por ejemplo, el predicado 
132 (13, 1, 124,221 

posee el valor falso. 


Los operadores < y C tienen conjuntos como ope- 
randos. El predicado 


ACB 


tiene el valor verdadero si los miembros del conjunto 
A están dentro del conjunto B, y tiene el valor falso en 
caso contrario. De esta forma el predicado 


(1,2) c (4,3, 1,2) 
posee el valor verdadero. Sin embargo, el predicado 
(HD1, LP4, RC5] c (HD1, RC2, HD3, LP1, LP4, LP6) 
posee el valorfalso porque el elemento RCS no está 


dentro del conjunto que se encuentra a la derecha del 
operador. 
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El operador € es similar a € . Sin embargo, si sus 
operandos son iguales posee el valor verdadero. Con- 
siguientemente, el valor del predicado 


(HD1, LP4, ROS] € (HD1, RC2, HD3, LP1, LP4, LP6) 


es falso, y el predicado 
(HDI, LP4, RC5) c (HDI, LP4, RCS) 


es verdadero. 

Un conjunto especiales el conjunto vacío O.En mate- 
máticas normales este operador se corresponde con el 
cero. El conjunto vacío tiene la propiedad de que es un 
subconjunto de todos los conjuntos restantes. Dos iden- 
tidades útiles relacionadas con el conjunto vacío son 


DUA=AYyDNMA=9D 


para todo conjunto A, en donde u es el operador unión, 
también conocido como «taza» (dado su forma); y Nes 
el operador intersección, conocido también como 
«gorra», 

El operador unión admite dos conjuntos y forma uno 
con todos los elementos del conjunto después de elimi- 
nar los duplicados. Así pues, el resultado de la expresión 


[Archivol, Archivo2, Impuesto, Compilador; u 
[Nuevolmpuesto, D2, D3, Archivo2] 


es el conjunto 


[Archivo1, Archivo2, Impuesto, Compilador, 
Nuevolmpuesto, D2, D3) 


El operador de intersección admite dos conjuntos y 
forma un conjunto que consta de los elementos comu- 
nes a los dos anteriores. Por tanto, la expresión 


(12, 4,99, 1) (1, 13,12,771 


da lugar a un conjunto (12,1). 


os matemáticos están entre los mejores 
ntos realizados porla mente humana, 
lus Hofstadter 


El operador diferencia de conjuntos Y, como el mis- 
mo nombre indica, forma un conjunto eliminando los 
elementos del segundo operando de entre los elemen- 
tos del primer operando. Consiguientemente el valor de 
la expresión 


[Nuevo, Viejo, Archivolmpuesto, 
ParamSistema M Viejo, ParamSistema] 


da lugar al conjunto (Nuevo,Archivolmpuesto). 
El valor de la expresión 


[a,b,c,d) MN (x, y) 


será el conjunto vacío O.El operador siempre propor- 
ciona un conjunto; sin embargo, en este caso no exis- 
ten elementos comunes entre sus operandos, de manera 
que el conjunto resultante carecerá de elementos. 
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El operador final es el producto cruzado x, conoci- 
do algunas veces también como producto cartesiano, 
el cual posee dos operandos que son conjuntos de pare- 
jas. El resultado es un conjunto de parejas en donde cada 
una se compone de un elemento tomado del primer ope- 
rando, combinado a su vez con un elemento del segun- 
do operando. La siguiente expresión es un ejemplo del 
producto cruzado 


(1,2) x(4,5,6) 
El resultado de esta expresión es 
(1,4), 0,5), (1,6), (2,4), (2,5), (2,6)) 


Hay que tener en cuenta que todos los elementos del 
primer operando se combinan con todos los elementos 
del segundo. 

Un concepto importante en los métodos formales es 
el operador conjunto potencia. Se trata de la colección 
de subconjuntos de ese conjunto. El símbolo que se uti- 
liza para este operador de conjunto en este capítulo es 

P . Este es un operador unario que cuando se aplica a 
un conjunto devuelve el conjunto de subconjuntos del 
operando. Por ejemplo, 


P (1,2,3) =(9, (1), (2), (3), (1,2), (1,3), 
(2,3), (1,2,3)) 


ya que todos los conjuntos son subconjuntos de [ 1,2,3). 


25.2.3. Operadores lógicos 


Otro componente importante de los métodos forma- 
les es la lógica: el álgebra de las expresiones verda- 
deras y falsas. Cualquier ingeniero del software 
entenderá el significado de los operadores lógicos 
comunes. Sin embargo, los operadores lógicos que 
están asociados a los lenguajes de programación 
comunes se escriben utilizando los símbolos disponi- 
bles en el teclado. Los operadores matemáticos equi- 
valentes son los siguientes: 


A 


Y 
v O 
= no 
> implica 


La cuantificación universal es una manera de con- 
feccionar una afirmación acerca de los elementos del 
conjunto que resulta ser verdadera para todos los miem- 
bros de ese conjunto. La cuantificación universal utili- 
za el símbolo Y. Veamos un ejemplo de la utilización 
de este símbolo 


VILJ:N:i>¡>2e>p 
en donde se lee que toda pareja de valores del conjunto 


de los números naturales, si ¡ es mayor que ¡, entonces 
Í? es mayor que 7?. 
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25.2.4. Sucesiones 


Una sucesión es una estructura matemática que mode- 
la el hecho consistente en que sus elementos están orde- 
nados. Una sucesión s es un conjunto de parejas cuyos 
elementos oscilan entre / y el elemento de mayor núme- 
ro. Por ejemplo, 


LA, Jones), (2, Wilson), (3, Shapiro), (4,Estévez)) 


es una sucesión. Los objetos que forman los primeros 
elementos de las parejas se conocen como dominio de 
una sucesión, y la colección de segundos elementos 
como intervalo de la sucesión. En este libro, las 
secuencias se indicarán empleando corchetes angula- 
res. Por ejemplo, la sucesión anterior se escribiría 
entonces como 


(Jones, Wilson, Shapiro, Estévez) 


A diferencia de los conjuntos, en una sucesión se per- 
mite la duplicidad, aunque su orden es muy importan- 
te. Por tanto 


(Jones, Wilson, Shapiro) + (Jones, Shapiro, Wilson ) 


Una sucesión vacía se representa mediante la for- 


ma (). 

En las especificaciones formales se utiliza un cierto 
número de operadores de sucesión. La concatenación, 
A ,es un operador binario que forma una sucesión que 
se construye añadiendo el segundo operando al final de 
su primer operando. Por ejemplo, 


(2,3, 34, 1) (12,33, 34, 200) 


da como resultado la sucesión (2, 3, 34, 1, 12,33, 34, 
200). 

Otros operadores que pueden aplicarse a las suce- 
siones son cabeza, cola, frente y último. El operador 
cabeza extrae el primer elemento de una sucesión; el 
operador cola proporciona los últimos n-/ elemen- 
tos finales de una sucesión de longitud n; por Último 
el operador Último extrae el elemento final de una 
sucesión; y el operador frente proporciona los últi- 
mos »- 1 elementos en una sucesión de longitud r. Por 
ejemplo, 


cabeza(Q, 3,34, 1,99, 101)=2 

cola(2, 3, 34, 1, 99, 101)=(3, 34, 1, 99, 101) 
último(2, 3, 34, 1,99, 101)= 101 

frente(2, 3,34, 1, 101)=(2, 3, 34, 1, 99) 


Dado que una sucesión es un conjunto de parejas, se 
pueden aplicar todos los operadores de conjuntos des- 
critos en la Sección 25.2.2. Cuando en un estado se uti- 
liza una sucesión, se debería designar utilizando la 
palabra clave seg. Por ejemplo, 


ListaArchivos: seq ARCHIVOS 
NingúnUsuario: N 


describen un estado con dos componentes: una suce- 
sión de archivos y un número natural. 
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25.3 


REA 


Para ilustrar la utilización de la notación matemática en 
la especificación formal de un componente de softwa- 
re, estudiaremos de nuevo el ejemplo del Gestor de Blo- 
ques de la Sección 25.1.3. Para recapitular, veremos que 
se utiliza un componente importante del sistema ope- 
rativo de una computadora que mantiene archivos cre- 
ados por usuarios. El gestor de bloques mantiene una 
reserva de bloques sin utilizar y también sigue la pista 
de aquellos bloques que se estén utilizando en ese 
momento. Cuando los bloques proceden de un archivo 
borrado, lo normal es añadirlos a una cola de bloques 
en espera a ser añadidos a la reserva de bloques no uti- 
lizados. En la Figura 25.2% se muestra un esquema en 
donde se representa este funcionamiento. 


¿Cómo se pueden representar 
os estados y los invariontes 
de datos utilizando los operadores 
lógicos y de conjuntos presentados 
anteriormente? 


Existe un supuesto conjunto BLOQUES, que se com- 
pone de un conjunto formado por todos los números de 
bloque, y un conjunto TodosLosBloques, que es un con- 
junto de bloques entre 1 y BloquesMax. Su estado se 
modelará mediante dos conjuntos y una sucesión. Los 
dos conjuntos son usados y libres. Ambos contienen 
bloques, es decir, el conjunto usados contiene los que 
se están utilizando actualmente en los archivos, y el con- 
junto libres contiene los que están disponibles para los 
archivos nuevos. La sucesión contendrá los conjuntos 
de bloques listos para ser liberados procedentes de archi- 
vos que se han borrado. 

El estado se puede describir de la siguiente forma 


usados, libres: Y” BLOQUES 
ColaBloques: seq P. BLOQUES 


Esta descripción de estado se asemeja a la declara- 
ción de variables de un programa. Afirma que usados y 
libres serán los conjuntos de bloques y que ColaBlo- 
ques será una sucesión, cada uno de cuyos elementos 
será un conjunto de bloques. El invariante de datos se 
escribirá de la siguiente manera 


usados MN libres = O A 
usados Y libres = TodosBloques A 
V i: dom ColaBloques - ColaBloques i E usados A 


V ¡j: dom ColaBloques .¡+j => ColaBloques im 
ColaBloquesj = O 


4 si no recuerda lo que ocurrió en la colección del gestor de bloques 
consulte la Sección 25.1.3 para revisar el invariante de datos, las pre- 
condiciones de las operaciones y las postcondiciones asociadas al 
gestor. 
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Referencia 


Para encontrar mós información sobre métodosformales visite la página 
archive.comlab.ox.ac.uk /formal-methods.html 


Los componentes matemáticos del invariante de datos 
se corresponden con los cuatro componentes del len- 
guaje natural marcados que se han descrito anterior- 
mente. En la primera línea del invariante de datos se 
establece que no habrá bloques comunes en la colec- 
ción de bloques usados y en la colección de bloques 
libres. En la segunda línea se establece que la colección 
de bloques usados y de bloques libres será siempre igual 
a la colección completa de bloques del sistema. La ter- 
cera línea indica que el elemento ¿-ésimo de la cola de 
bloques será siempre un subconjuntode los bloques usa- 
dos. La última línea afirma que si dos elementos de la 
cola de bloques no son iguales, entonces no existirán 
componentes comunes en estos dos elementos. Los dos 
últimos componentes en lenguaje natural del invarian- 
te de datos se implementan como consecuencia del 
hecho consistente en que usados y libres son conjuntos, 
y por tanto no contendrán duplicados. 

La primera operación que se va a definir es la que 
elimina un elemento de la parte anterior de la cola de 
bloques. La precondición es que debe de existir al menos 
un elemento en la cola: 


HColaBloques >0, 


La postcondición es que es preciso eliminar la cabe- 
za de la cola y es preciso ubicarla en la colección de 
bloques libres, y es preciso ajustar la cola para mostrar 
esa eliminación: 

usados' = usadosWcabeza ColaBloques A 

libres” = libres U cabeza ColaBloques A 

ColaBloques' = cola ColaBloques 


Una convención que se utiliza en muchos méto- 
dos formales es que el valor de una variable después 
de una cierta operación lleva el signo prima. Por tan- 
to, el primer componente de la expresión anterior afir- 
ma que el nuevo conjunto de bloques usados 
(usados”)será igual al conjunto bloques usados ante- 
rior menos los bloques que hayan sido eliminados. 
El segundo componente afirma que el nuevo conjunto 
de bloques libres (libres”)será el conjunto viejo de 
bloques libres después de añadir la cabeza de la cola 
de bloques. El tercer componente afirma que la cola 
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nueva de bloques será igual a la cola del viejo valor 
de la cola de bloques, es decir, a todos los elementos 
de la cola salvo el primero. Una segunda operación 
es la que se encarga de añadir una cola de bloques 
BloquesA a la cola de bloques. La precondición es 
que BloquesA sea en ese momento un conjunto de 
bloques usados: 


BloquesA < usados 


Cómo se pueden representar 
las pretonditiones y las 
posttonditiones? 
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La postcondición es que el conjunto de bloques se 
añade al final de la cola de bloques y el conjunto de blo- 
ques libres y usados permanece invariable: 


ColaBloques” =ColaBloques 4 ( ABlocks)A 
usados” =usados A 
libres? = libres 


No cabe duda de que la especificación matemática 
de la cola de bloques es considerablemente más rigu- 
rosa que una narración en lenguaje natural o un mode- 
lo gráfico. Este rigor adicional requiere un cierto 
esfuerzo, pero los beneficios ganados a partir de una 
mejora de la consistencia y de la completitud puedan 
justificarse para muchos tipos de aplicaciones. 


Un lenguaje de especificación formal suele estar com- 
puesto de tres componentes primarios: (1) una sinta- 
xis que define la notación específica con la cual se 
representa la especificación; (2) una semántica que 
ayuda a definir un «universo de objetos» [WIN90] que 
se utilizará para describir el sistema; y (3) un conjun- 
to de relaciones que definen las reglas que indican cuá- 
les son los objetos que satisfacen correctamente la 
especificación. 

El dominio sintáctico de un lenguaje de especifica- 
ción formal suele estar basado en una sintaxis derivada 
de una notación estándar de la teoría de conjuntos y del 
cálculo de predicados. Por ejemplo, las variables tales 
como X,y, y z describen un conjunto de objetos que están 
relacionados a un problema (algunas a veces se deno- 
minan el dominio del discurso) y se utilizan junto con 
los operadores descritos en la Sección 25.2. Aunque la 
sintaxis suele ser simbólica, también se pueden utilizar 
iconos (símbolos gráficos como cuadros, flechas y cír- 
culos) si no son ambiguos. 

El dominio semántico de un lenguaje de especifica- 
ción indica la forma en que ese lenguaje representa los 
requisitos del sistema. Por ejemplo, un lenguaje de pro- 
gramación posee un conjunto de semánticas formales 
que hace posible que el desarrollador de software espe- 
cifique algoritmos que transforman una entrada en una 
salida. Una gramática formal (tal como BNFE) se puede 
utilizar para describir la sintaxis del lenguaje de pro- 
gramación. Sin embargo, un lenguaje de programación 
no es un buen lenguaje de especificación, porque sola- 
mente puede representar funciones computables. Un 
lenguaje de especificación deberá poseer un dominio 
semántico más amplio; esto es, el dominio semántico 
de un lenguaje de especificación debe de ser capaz de 
expresar ideas tales como «Para todo x de un conjunto 
infinito A, existe un y de un conjunto infinito B tal que 
la propiedad P es válida para x e y» [WIN9O]. Otros len- 
guajes de especificación aplican una semánticaque hace 
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posible especificar el comportamiento del sistema. Por 
ejemplo, se puede desarrollar una sintaxis y una semán- 
tica para especificar los estados y las transiciones entre 
estados, los sucesos y sus efectos en las transiciones de 
estados, o la sincronización y la temporización. 

Es posible utilizar distintas abstracciones semánti- 
cas para describir un mismo sistema de diferentes 
maneras. Eso se ha hecho de manera formal en los 
Capítulos 12 y 21. El flujo de datos y el procesamien- 
to correspondiente se describía utilizando el diagrama 
de flujo de datos, y se representaba el comportamien- 
to del sistema mediante un diagrama de transición entre 
estados. Se empleaba una notación análoga para des- 
cribir los sistemas orientados a objetos. Es posible uti- 
lizar una notación de modelado diferente para 
representar el mismo sistema. La semántica de cada 
representación proporciona una visión complementa- 
ria del sistema. Para ilustrar este enfoque cuando se 
utilicen los métodos formales, supóngase que se utili- 
za un lenguaje de especificación formal para describir 
el conjunto de sucesos que dan lugar a que se produz- 
ca un cierto estado dentro de un sistema. Otra relación 
formal representa todas aquellas funciones que se pro- 
ducen dentro de un cierto estado. La intersección de 
estas dos relaciones proporciona una indicación de los 
sucesos que darán lugar que se produzcan funciones 
específicas. 

En la actualidad se utiliza toda una gama de lengua- 
jes formales de especificación: CSP [HIN95, HOR85], 
LARCH [GUT93], VDM [JON91] y Z [SPI88, SPI92] 
son lenguajes formales de especificación representati- 
vos que muestran las características indicadas anterior- 
mente. En este capítulo, se utiliza el lenguaje de 
especificación Z a efectos de ilustración. Z está acom- 
pañado de una herramienta automatizada que almace- 
na axiomas, reglas de inferencia y teoremas orientados 
a la aplicación que dan lugar a pruebas de corrección 
matemáticas de la especificación. 
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Las especificacionesen Z se estructuran como un con- En esta sección, se utiliza el lenguaje de especifica- 
junto de esquemas —son estructurasparecidas acuadros ción Z para modelar el ejemplo del gestor de bloques 
que presentan variables y que especificanla relación exis- que se presentaba en la Sección 25,1.3 y se trataba pos- 
tente entre las variables —. Un esquema es, en esencia,  teriormente en la Sección 25.3. En la Tabla 25.1 se pre- 
una especificaciónformal análoga a la subrutinao el pro- senta un resumen de la notación del lenguaje Z. El 


cedimiento de un lenguaje de programación. Del mismo siguiente ejemplo de esquema describe el estado del 
modo que los procedimientos y las subrutinasse utilizan gestor de bloques y del invariante de datos: 

para estructurar un sistema, los esquemas se utilizan para 

estructurar una especificaciónformal. 


La notación Z está basada en la teoría de conjuntos contipos y en la lógica de primer orden. Z proporcio- 
na una estructura denominada esquema, para describir el estado y las operaciones de una especificación. 
Los esquemas agrupan las declaraciones de variables con una lista de predicados que limitan los posibles 
valores de las variables. En Z el esquema X se define en la forma 


X 
declaraciones 


predicados 


Las funciones constantes globales se definen en la forma 
declaraciones 


predecibles 


La declaración proporciona el tipo de la función o constante, mientras que el predicado proporciona su 
valor. En esta tabla solamente se presenta un conjunto abreviado de símbolos de Z. 


Conjuntos: 
s:N x S se declara como un conjunto de X. 
xeS x es miembro de $, 
xÉS x noes miembro de S 
Sc T Ses un subconjunto de 7: Todo miembro de Sestá también en 7. 
SuT La unión de S y 7: Contiene todos los miembros de So Toambos. 
snT La inserción de Sy 7: Contiene todos los miembrostanto de Scomo de 7, 
ST La diferencia de S y 7: Contienetodos los miembros de Ssalvo los que estántambién en 7. 
10) Conjunto vacío: No contiene miembros. 
104 Conjunto unitario: Solamente contiene a x. 
IN El conjunto de los números naturales O, 1,2.... 
S. FX Se declara S como un conjunto finito de X. 
max (S) El máximo del conjunto no vacío de números $. 
Funciones: 
EX Y Se declara como una inyección parcial de Xe Y. 
dom f El dominio de f. Dícese del conjunto de valores de x para los cuales está definido Ax). 
ran f El rango de f. El conjunto de valores que toma Ax) cuando x recorre el dominio de f, 
FO lx > y) Una función que coincide con fsalvo que x se hace corresponder con y. 
ba<f Una función igual que f, salvo que xse ha eliminado de su dominio. 
Lógica: 
PAQ Py O: Esverdadero si tanto P como Q son verdaderos. 
P=>0 P implica Q: Es verdadero tanto si Q es verdadero como si P es falso. 
0S' = ES Ningún componente del esquema S cambia en una operación. 


TABLA 25.1. Resumen de la notaciónZ. 
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Gestionar Bloques 


usados, libres: P'” BLOQUES 
ColaBloques: seq P BLOQUES 


usados MN libres =O A 
usados M libres =TodosBloques 

V ¡: dom ColaBloques . ColaBloques i E usados A 
V i,¡: dom ColaBloques «¡+ ¡=> 
ColaBloques i n ColaBloques j =%W 


Referencia Web 


Información detallada sobre el lenguaje Z en donde 
se incluye FAQ se puede encontrar en 
archive.comlab. ox.ac.uk /z.html 


El esquema se compone de dos partes. La primera 
está por encima de la línea central representando las 
variables del estado, mientras que la que se encuentra 
por debajo de la línea central describe un invariante de 
los datos. Cuando el esquema que representa el inva- 
riante y el estado se utiliza en otro esquema, va prece- 
dido por el símboloA. Por tanto, si se utiliza el esquema 
anterior en uno que describa, por ejemplo, una opera- 
ción, se representaría mediante AGestorBloques. Como 
la afirmación anterior establece, los esquemas se pue- 
den utilizar para describir operaciones. El ejemplo 
siguiente describe la operación que elimina un elemen- 
to de una cola de bloques: 
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Eliminar Bloques 
AGestorBloques 
ColaBloques > 0, 
usados” =usadosX cabeza ColaBloques A 


libres” = libres Y cabeza ColaBloques A 
ColaBloques' = cola ColaBloques 


La inclusión de AGestorBloques da como resultado 


todas las variables que componen el estado disponible 
en el esquema EliminarBloques, y asegura que el inva- 
riante de datos se mantendrá antes y después de que se 
ejecute la operación. 

La segunda operación, que añade una colección de 
bloques al final de la cola, se representa de la manera 
siguiente: 


Añadir Bloques 


AGestorBloques 
BloquesA? : BLOQUES 


BloquesA? C usados 
ColaBloques” = ColaBloques (BloquesA?) 
usados” = usados A 

libres” = libres 


Por convención en Z, toda variable que se lea y que 
no forme parte del estado irá terminada mediante un sig- 
no de interrogación. Consiguientemente, BloquesA?, 
que actúa como parámetro de entrada, acaba con un sig- 
no de interrogación. 


El interés creciente en la tecnología de objetos ha 
supuesto que los que trabajan en el área de los méto- 
dos formales hayan comenzado a definir notaciones 
matemáticas que reflejan las construcciones asocia- 
das a la orientación a objetos, llamadas clases, heren- 
cia e instanciación. Se han propuesto diferentes 
variantes de las notaciones existentes, principalmen- 
te las que se basan en Zy el propósito de esta sec- 
ción es examinar Object Z que desarrollaron en el 
Centro de Verificación de Software de la Universidad 
de Queensland —. 

Object Z es muy similar a Z en detalle. Sin embar- 
go, difiere en lo que se refiere a la estructuración de los 
esquemas y a la inclusión de las funciones de herencia 
e instanciación. 

A continuación se muestra un ejemplo de especifi- 
cación en Object Z. Aquí se representa la especificación 
de una clase que describe una cola genérica que puede 
tener objetos de cualquier tipo. 
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Cola[T] 


numObjetosMax : ÑN 
numObjetosMax 1100 
cola: segT 
Fcola InumObjetosMax 
INIT 
cola =() 
Añadir — 
A(numObjetosMax) 


elemento? : T 
ttcola < numObjetosMax 
cola? = cola < elemento? > 


Extraer 
A(numObjetosMax) 
elemento! : T 
cola + <> 
elemento! = cabeza cola 
cola? = cola cola 
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Se ha definido una clase que tiene una variable de 
instancia cola, es decir, una secuencia que tiene obje- 
tos del tipo T, donde T puede ser de cualquier tipo; 
por ejemplo, puede ser un entero, una factura, un gru- 
po de elementos de configuración o bloques de 
memoria. Debajo de la definición de cola se leen unos 
esquemas que definen la clase. La primera define una 
constante que tendrá un valor no mayor de 100. El 
siguiente especifica la longitud máxima de la cola y 
los dos esquemas siguientes Añadir y Extraer defi- 
nen los procesos de añadir y extraer un elemento de 
la cola. 

La precondición de Añadir especificaque cuando se 
añade a la cola un objeto elemento? no debe tener una 
longitud mayor a la permitida; y la postcondición espe- 
cifica lo que ocurre cuando se ha finalizado la adición 
de elementos. La precondición de la operación Extraer 
especifica que para que esta operación se haga con éxi- 
to la cola no debe estar vacía, y la postcondición debe 
definir la extracción de la cabeza de la cola y su colo- 
cación en la variable elemento! 

Esto es, por tanto, la especificación básica de la cla- 
se de un objeto en Object Z. Si quisiéramos utilizar un 
objeto definido por dicha clase, sería relativamente sim- 
ple de hacer. Por ejemplo, supongamos que se está defi- 
niendo parte de un sistema operativo que manipulaba 
procesos que representan los programas en ejecución y 
que tomamos la decisión de que los procesos tenían que 
estar en dos colas, una con los procesos de alta priori- 
dad y la otra con aquellos de baja prioridad, y donde la 
prioridad la utilice el planificador del sistema operati- 
vo con el propósito de decidir cual es el siguiente pro- 
ceso a ejecutar. La primera sentencia de Object Z 
necesaria instanciará la clase de cola general en una que 
contenga procesos. 


ColaProc == Cola[ PROCESOS] 
[procO 1 cola, proc? | elemento? proc! | elemento! ] 


Se puede decir que todo lo que hace es reemplazar 
el tipo Tpor PROCESOS en la definición de la clase, la 
cola general cola por la cola de los procesos procQ y 
los parámetros generales de entrada y salida elemento? 
y elemento!, por aquellos parámetros de proceso proc ?, 
y proc!. El símbolo / representa una forma de sustitu- 
ción de texto. 

El siguiente paso, como se muestra a continuación, 
es definir una clase que describe las dos colas. Esta cla- 
se utiliza las operaciones definidas en la clase Cola. 
Supongamos que las siguientes Operaciones son nece- 
sarias: 


e añadirAlta, añade un proceso a la cola de los proce- 
sos de alta prioridad. 


e añadirBaja, añade un proceso a la cola de los pro- 
cesos de baja prioridad. 


e [NIT inicializa las colas de alta y baja prioridad. 


e totalProcesos devuelve el número total de procesos 
que están en las colas. 


alta, baja ¡ColaProc 
alta % baja 


INIT 


alta.INIT A baja INIT 


total! : Ñ 
total! =: Falta + Hbaja 


La primera línea define el esquema. La segunda y 
tercera definen el estado y el invariante del estado. En 
este caso el estado se compone de dos colas de proce- 
so bien diferenciadas: alta y baja. 

A la definición del estado le sigue la definición de 
cuatro operaciones. INIT se define como la aplicación 
de la operación heredada /NIT en las colas alta y baja, 
añadirAlta se define como la aplicación de la opera- 
ción heredada añadir en el componente del estado alta; 
añadirBaja se define como la aplicación de la opera- 
ción heredada añadir sobre el componente de estado 
baja, y, finalmente, la operación totalProcesos se defi- 
ne como la suma de tamaños de las colas individuales 
alta y baja. 

Consecuentemente, esto es un ejemplo de instancia- 
ción en acción, donde los objetos definidos por un esque- 
ma Object Z se utilizan en otro esquema. Con esto se 
puede definir la herencia. 

Para poder llevar a cabo la definición de herencia, 
examinemos otro ejemplo, el de una tabla de símbolos. 
Estas tablas se utilizan constantemente en aplicaciones 
que contienen los nombres de empleados en sistemas 
de personal, nombres de impresoras en sistemas opera- 
tivos, nombres de carreteras en sistemas de navegación 
para vehículos, y otros. Para describir la herencia, pri- 
mero definiremos una tabla genérica de símbolos, a con- 
tinuación la utilizaremos y mostraremos cómo se puede 
heredar del esquema Z que la define. En primer lugar 
se deben describir informalmente las operaciones y el 
estado necesarios. 

El estado estará compuesto de un conjunto del tipo 
T, Suponemos que no habrá más de 100 objetos y defi- 
niremos una serie de operaciones que actuarán sobre el 
estado: 


e [NIT que inicializa la tabla de símbolos para que esté 
vacía. 


e añadir que añade un objeto a la tabla de símbolos. 
e extraer que extrae un objeto de la tabla de símbolos. 


e número que retorna con el número de objetos de la 
tabla de símbolos. A continuación se muestra esta 
definición. 


www.elsolucionario.net 


TablaSímbolo[T] 


| numObjetosMax :ÑN 
MaxElem < 100 
tabla :T 


ftabla < MaxElem 


INTT 
tabla = f) 


Añadir 


A(tabla) 

obieto? : T 

tttabla < MaxElem 

tabla” = tabla u [ objeto?) 


Extraer 


A(tabla) 

objeto? : T 

objeto?e tabla 

tabla* = tablax (objeto ?] 


número 


E(tabla) 
numTablaln! : N 
numTablaln! =*tabla 


Estas son operaciones muy simples que conllevan 
operaciones estándar de conjuntos como Uu, y que 
siguen el formato mostrado en el ejemplo de colas. La 
operación añadir se definirá solo si la tabla tiene espa- 
cio para el objeto que se va a añadir, y la operación 
extraer solo se define si el objeto que se va a extraer 
está dentro de la tabla de símbolos. La operación núme- 
ro no afecta al estado, y de aquí que incluya el ele- 
mento (tabla). 

Si queremos instanciar la tabla como una tabla de 
nombres de empleados del tipo EMPLEADO, se requie- 
re todo lo siguiente: 


TabEmpleado == TablaSimbolos[ EMPLEADO] 
[emp/tabla,emp? Jobjeto? emptlobjeto!] 


donde la tabla se convierte en una tabla con objetos 
EMPLEADO y donde los parámetros de entrada defi- 
nidos de forma genérica han sido sustituidos por pará- 
metros específicos emp? y emp! 

A continuación se muestra el esquema Object Z que 
describe la nueva tabla de empleados mediante la ins- 
tanciación; simplemente involucra la redefinición de los 
operadores que se acaban de definir. 


tablaEmp 


e : TabEmpleados 


AñadirEmp £ e.añadir 
ExtraerEmp £ e.extraer 
InitEmp 2 e.INIT 
NúmeroEmp £ e.número 
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Ahora supongamos que se necesita utilizar la heren- 
cia. Para mostrar este caso, supongamos una operación 
encontrar que devuelve un valor encontrado si se encuen- 
tra un objeto en la tabla de símbolos, y un valor no encon- 
trado si no está en la tabla. Vamos a suponertambién una 
aplicación en la que cuando se ejecutala operación encon- 
trar se suele utilizar el mismo objeto que está en la tabla. 
Aseguraremos que, cuando se aplica antes esta opera- 
ción, antes de empezar se comprobará que éste es el obje- 
to, lo que podría suponer una búsqueda prolongada en la 
tabla. Antes de definir este esquema se debe de utilizar 
el esquema original de tabla de símbolos para incluiresta 
información. En primer lugar necesitamos un miembro 
diferenciado de la tabla que se conoce como FrecElem. 
Este es el elemento que se utiliza con más frecuencia. La 
definición de la tabla nueva es: 


TablaDif[T] 


TablaSímbolos[T] 
FrecElem : T 
Encontrar 


A( FrecElem) 

aSerEncontrado? : T 

estado! : [encontrado noencontrado) 
aserEncontrado? = FrecElem v aSerEncontrado? 
Etabla= 

estado! = encontrado a FrecElem ” = aSerEncon- 
trado? 

asSerEncontrado? + FrecElem A aSerEncontrado? 
£ tabla = 


estado! = noEncontrado 


Aquí todas las operaciones definidas para Tabla- 
Símbolos se heredan sin cambios como está la variable 
de instancia tabla. La nueva operación encontrar utili- 
za una variable FrecElem que forma parte del nuevo 
esquema TablaDif de Object Z. 

Esta operación comprueba si el parámetro de entrada 
de encontrar es el mismo que el elemento frecuente que 
se está recuperando varias veces o está dentro de la tabla. 
Si es así, entonces el estado correcto encontrado se devuel- 
ve y el elemento frecuente se actualiza. Si el elemento no 
es el elemento frecuente y no está dentro de la tabla enton- 
ces se devuelve el estado noEncontrado. 

Este esquema se puede utilizar entonces dentro de 
una aplicación de empleados especificando: 


TabEmpleadoFrec == TablaDif[ EMPLEADO] 
[emps/tabla,emp? /objeto? emp! EmpfreciObjetofrec] 


EmpleadoFrec 


e : TabEmpleadoFrec 
AñadirEmpFrec 2 e AÑADIR 
ExtraerEmpFrec 2 e. EXTRAER 
IntEmpFrec 2 e.INIT 
NúmeroEmpFrec £ e. NUMERO 
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Esto es una introducción corta para mostrar la mane- 
ra de empezar a utilizar las notaciones formales para la 
especificación de sistemas orientados a objetos. La mayor 
parte del trabajo que se ha llevado a cabo dentro de esta 
área ha empleado la noción Z y se ha intentado construir 
basado en las ideas de estado, precondición, postcondi- 
ción e invariante de datos, que se ha descrito en la sec- 


ción anterior, para implementar las funciones para la ins- 
tanciación y la herencia. El trabajo en esta área está toda- 
vía a nivel de investigación con pocas aplicaciones. Sin 
embargo, durante el período de vida de esta edición las 
notaciones formales orientadas a objeto deberían expe- 
rimentar el mismo nivel de penetración industrial que 
notaciones estándar tales como las notaciones Z. 


Una de las características principales de las dos técni- 
cas de especificación descritas anteriormente, Z y Z++, 
es el hecho de que están basadas en la noción de esta- 
do: una colección de datos que se ven afectados por ope- 
raciones definidas por expresiones escritas en el cálculo 
del predicado. 

Una técnica alternativa se conoce como especifica- 
ción algebraica. Y consiste en escribir sentencias mate- 
máticas que narran el efecto de las operaciones 
admisibles en algunos datos. Esta técnica tiene la ven- 
taja principal de apoyar el razonamiento de manera 
mucho más fácil que los métodos basados en el estado. 

El primer paso al escribir una especificación alge- 
braica es determinar las operaciones necesarias. Por 
ejemplo, podría darse el caso de que un subsistema que 
implemente una cola de mensajes en un sistema de 
comunicación necesite operaciones que extraigan un 
objeto del comienzo de la cola, que devuelvan el núme- 
ro de objetos de una cola y que comprueben si la cola 
está vacía. 

Una vez que se han desarrollado estas operaciones, 
se puede especificar la relación que existe entre ellas. 
Por ejemplo, el especificador podría describir el hecho 
de que cuando se añade un elemento a la cola el núme- 
ro de elemento de esa cola aumenta en un elemento. 
Para mostrar una impresión del aspecto de una especi- 
ficación algebraica reproduciremos dos especificacio- 
nes. La primera es para una cola, y la segunda para una 
tabla de símbolos. Asumimos que las operaciones 
siguientes son necesarias para la cola: 


e ColaVacía. Devuelve un valor Booleano verdadero 
si la cola a la que se aplica está vacía y falso si no lo 
está. 


e añadirObjeto. Añade un objeto al final de la cola. 
e extraerObjeto. Extrae un objeto del final de la cola. 


e primero. Devuelve el primer elemento de una cola, 
y esta no se ve afectada por esta operación. 


e Último. Devuelve el último elemento de una cola, y 
esta no se ve afectada por esta operación. 


e estáVacia? Devuelve un valor Booleano verdadero 
si la cola está vacía,' y falso si no lo está. 


A continuación se muestran las primeras líneas de la 
especificación y las operaciones de esta cola: 


Nombre: colaParcial 
Clases: cola(Z,) 


Operadores: 

colaVacía: > cola(Z,) 
añadirElemento: Z x cola(Z) > cola(Z) 
extraerElemento: Z x cola(Z) > cola(Z,) 
primera: cola(Z) > Z 

última: cola(Z) => Z 
estáVacia? : cola(Z) > Booleana 


La primera línea es la que da el nombre al tipo de 
cola. La segunda línea afirma que la cola manejará cual- 
quier tipo de entrada Z; por ejemplo, Z podría ser men- 
sajes, procesos, empleados esperandoentrar a un edificio 
O aeronaves esperando para aterrizar en un sistema de 
control del tráfico aéreo. 

El resto de la especificación describe las signaturas 
de las operaciones: cuáles son los nombres y el tipo de 
elemento que procesan. La definición de colaVacía afir- 
ma que no toma argumentos, y que da una cola que está 
vacía; la definición de añadirElemento afirma que toma 
un objeto del tipo Z y una cola con los objetos del tipo 
Z y entonces da una cola de objetos del tipo Z, y así 
sucesivamente. 

Esto es solo la mitad de la especificación —el resto 
describe la semánticade cada operación en función de la 
relación con otras operaciones —.A continuación, se 
muestran algunos ejemplos de este tipo de especificación. 

La primera afirma que estáVacía? será verdadera para 
una cola vacía y falsa si existe al menos un objeto en la 
cola; cada una de estas propiedades se expresan en una 
sola línea 


estáVacia?(cola Vacía) = verdadera 
estáVacia*(añadirObjeto(z,q)) = falsa 


La definición de la operación primera es 
primera(añadirElemento(z,q)) =Z 


la cual establece que primero volverá con el primer ele- 
mento de la cola. 

Con esto se puede ver el estilo de especificación. 
Para concluir ofreceremos una especificación com- 
pleta de una tabla de símbolos. Esta es una estructu- 
ra de datos que contiene una colección de objetos sin 
duplicados. Estas tablas se encuentran prácticamente 
en todos los sistemas de computadoras: se utilizan 


www.elsolucionario.net 


para almacenar nombres en sistemas de empleados, 
identificadores de aeronaves en sistemas de control 
del tráfico aéreo, programas en sistemas operativos y 
otros. 


e tablaVacía. Construye una tabla de símbolos vacía. 
e añadirElemento. Añade un símbolo a una tabla de 
símbolos que ya exista. 


extraerElemento. Extrae un símbolo de una tabla de 
símbolos que ya exista. 


estáenTabla? Será verdadero si un símbolo está en 
una tabla y falso si no está. 


unir. Une el contenido de dos tablas de símbolos. 


común. Toma dos tablas de símbolos y retorna con 
los elementos comunes de cada tabla. 


esParteDe. Retorna verdadero si una tabla de sím- 
bolos está en otra tabla de símbolos. 


esIgual. Retorna verdadero si una tabla de símbolos 
es igual a otra tabla de símbolos. 


estáVacía. Retorna verdadero si la tabla de símbolos 
está vacía. 


A continuación se muestra la definición de las firmas 
de los operadores 
Tabla de nombres 
Clases: tablaSímbolos(Z)con = 


Operadores: 

tablavacía: > tablaSímbolos(Z) 

añadirElemento: Z x tablaSímbolos (Z) > 
tablaSímbolos (Z) 

extraerElemento: Z x tablaSímbolos (Z) > 


tablaSímbolos (Z) 


Z x tablaSímbolos (Z) => 
Booleano 


estáenTabla?: 


unir: tablaSímbolos (Z) x 
tablaSímbolos (Z) => 
tablaSímbolos (Z) 

común: tablaSímbolos (Z) x 
tablaSímbolos (Z) —> 
tablaSímbolos Z) 

esParteDe?: tablaSímbolos (Z) x 
tablaSímbolos (Z) —> Booleano 

esIgual?: tablaSímbolos (Z) x 
tablaSímbolos (Z) > Booleano 

estáVacía? : 


tablaSímbolos (Z) —> Booleano 


Todas las definiciones se pueden entender al margen 
de la línea siguiente 


Clases: tablaSímbolos (Z) con = 


la cual establece que los objetos del tipo Z se asociarán 
con un operador de igualdad. 


451 


unrÍTULO 25 MÉTODOS FORMALES 


La definición del operador añadirElemento es 


añadirElemento(s2, añadirElemento(s 1,8)) = 
sis 1=s2 entonces añadirElemento(s2,s) 
o si no añadirElemento(s1,añadirElemento(s2,s)) 


Esto establece que si se realizan dos sumas en la tabla 
de símbolos y se intenta añadir el mismo elemento dos 
veces, solo será equivalente a la suma de uno de los dos 
elementos. Sin embargo, si los elementos difieren, enton- 
ces el efecto será el de añadirlos en un orden diferente. 

La definición de extraerElemento es 


extraerElemento(s l,tablaVacía) = tablavacía 
extraerElemento (sl, añadirElemento (s2,s)) = 

sis 1=s2 entonces extraerElemento (s 1,s) 

o sino añadirElemento (s2,extraerElemento (s1,s)) 


Esta definición establece que si se intenta extraer un 
elemento de una tabla vacía se elaborará la construc- 
ción de tabla vacía, y que cuando se extrae un elemen- 
to sl de una tabla que contiene un objeto s2, entonces 
si sl y s2 son idénticos el efecto es el de extraer el obje- 
to sl, y si no son iguales el efecto es el de dejar s2 y 
extraer el objeto sl . 

La definición de estáenlabla? es 
estáenTabla?(sl, tablavacía) = falso 
estáenTabla(sl, añadirElemento(s2,s)) = 


sisl =s2 entonces es verdadero o si no está 
en Tabla? (s L,s) 


En esta definición se establece que un elemento no 
puede ser miembro de una tabla de símbolos vacía y 
que el resultado de aplicar estaenTabla? y s] auna tabla 
que esté formada de s/ y $2 devolverá un valor verda- 
dero si sl es igual a s2; si no son iguales hay que apli- 
car estáenTabla? a sl. 

A continuación se muestra la definición de unir: 
unir(s, tablavacía) =s 
unirís, añadirElemento(s1,t)) = 

añadirElemento(sl ,unir (s,t)) 


Aquí se establece que uniendo una tabla vacía y una 
tabla s da como resultado la construcción de una tabla 
vacía s, y que el efecto de unir dos tablas en donde una 
de ellas tenga el símbolo sl es equivalente a añadir sl 
al resultado de unir dos tablas. 

A continuación se muestra la definición de común: 
común(s, tablavacía) = tablavacía 
común(s,añadirElemento(s1,t)) =si estáenTabla?Y(s1,s) 

entonces añadirElemento(sl, 
común(s,t)) 
o sino común(s,t) 


Esta definición establece que la tabla compuesta de 
los elementos comunes de la tabla vacía y cualquier 
otra tabla es siempre la tabla vacía. La segunda línea 
afirma que, si se unen dos tablas, entonces, si hay un 
elemento común sl, este se añade al conjunto común, 
o de lo contrario se forma el conjunto común de dos 
conjuntos. 
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La definición de esParteDe? es la siguiente: 
esParteDeY(tablaVacía,s) = verdadero 
esParteDe(añadirElemento(s 1,5)) = 

siestáenTabla? (s1,t) entonces esParteDe?(s,t) 
o si no es falso 


Esta definición establece que la tabla de símbolos 
vacía siempre es parte de cualquier tabla de símbolos. 
La segunda línea establece que si la tabla t contiene un 
elemento en s entonces se aplica esPartede? para ver si 
s es una subtabla de £. 

A continuación se presenta la definición de esfgual?: 


esIgual?(s,t) = esParteDeYs,t) A esPartede?(t,s) 


Esta definición establece que las tablas de símbolos 
son iguales si están dentro una de otra. La definición 
final de estáVacia? es así de sencilla: 

estáVaciaY(tablaVacía) = 

estáVacia(añadirElemento(s 1,1)) = 


verdadero 
falso 


Aquí se establece simplementeque la tabla vacía está 
vacía y que una tabla que contienepor lo menos un obje- 
to no estará vacía. 

Por tanto, la descripción completa de la tabla de sím- 
bolos es la siguiente: 


Tabla de nombres 
Clases: tablaSímbolos(Z) con = 


Operadores: 

tablavacía: > tablaSímbolos(Z) 

añadirTabla: Z x tablaSímbolos (Z) > 
tablaSímbolos (Z) 

extraerBlemento: Z x tablaSímbolos (Z) > 
tablaSímbolos (Z) 

estáenTabla?: Z x tablaSímbolos (Z) => 
Booleana 

unir: tablaSímbolos (Z) x 
tablaSímbolos (Z) => 
tablaSímbolos (Z) 

común: tablaSímbolos (Z) x 


tablaSímbolos (Z) — 
tablaSímbolos (Z,) 


esParteDe?: Z x tablaSímbolos (Z) x 
tablaSímbolos (Z) —> Booleana 

esIgual?: Z x tablaSímbolos (Z) x 
tablaSímbolos (Z) —> Booleana 

estáVacia?: tablaSímbolos (Z) — Booleana 


añadirElemento(s2,añadirElemento(s 1,s)) = 
sisl =s2 entonces añadirElemento(s2,s) 
o si no añadirElemento(s1, añadirElemento(s2,s)) 


extraerElemento(sl, tablavacía) = tablavacía 
extraerElemento(s1, añadirElemento(s2,s)) = 

si sl =s2 entonces extraerElemento(slÍ,s) 

o si no añadirElementos(s2,extraerElemento(s 1,s)) 

estáenTabla?(sl, tablavacía) =falso  «. 
estáenTabla?(s1, añadirElemento(s2,s)) = 

si sl =s2 entonces verdadero 

o si no estáenTabla?(s1,s) 


unir(s, tablavacía) =s 
unirís, añadirElemento(sl,s)) = 
añadirElemento(sl, unir(s,b) 


común(s, tablavacía) = tablavacía 

común(s, añadirElemento(s 1,t)) = 
si estáenTabla(s1,s) 
entonces añadirElemento(sl, común(s,t)) 
o sino común (s,t) 


esParteDeYA(tablaVacía,s) = verdadero 
esParteDe(añadirElemento(ts l,s),t) = 
si estáenTabla?*(s 1,t) entonces esParte De*(s,t) 
o si no falso 


esIgual*(s,t) =esParteDeY(s,t) A esParteDe?(t,s) 
estáVacialtablaVacía) = 


está Vacia?*(añadirElemento(s 1l,s) = 


verdadero 


falso 


Tales especificaciones son bastante difíciles de cons- 
truir, y el problema principal es qúe no se sabe cuándo 
hay que parar de añadir sentencias que relaten opera- 
ciones y que tienden a ser mucho más prolongadas que 
sus equivalentes basados en el estado. Sin embargo, 
matemáticamente son más puras y más fáciles para lle- 
var a cabo el razonamiento. 


Las dos secciones anteriores han descrito Z y la deri- 
vación orientada a objetos Object Z. El principal pro- 
blema de estas especificaciones y de las notaciones 
matemáticas similares es que no tienen las funciones 
para especificar los sistemas concurrentes: aquellos 
donde se ejecutan un serie de procesos al mismo tiem- 
po + frecuentemente con un grado elevado de comu- 
nicación entre estos procesos—. Aunque se han 
realizado muchos esfuerzos por modificar notaciones 
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tales como Z para acompañar la concurrencia, no se 
ha hecho con mucho éxito ya que nunca se diseñaron 
realmente con esta idea en la cabeza. Donde sí se ha 
hecho con éxito ha sido en el desarrollo de notacio- 
nes formales de propósito especial para concurrencia, 
y el propósito de esta sección es describir una de las 
más conocidas: PSI (Procesos Secuenciales interco- 
municados) [CSP (Communicating Sequential Pro- 
cesses)]. 
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PSI fue desarrollado en Oxford por el científico 
informático inglés Tony Hoare. La idea principal que 
respalda esta notación es que se puede ver un siste- 
ma como un conjunto de procesos secuenciales (pro- 
gramas simples no concurrentes) que se ejecutan y 
se comunican con otros procesos de manera autóno- 
ma. Hoare diseñó PSI para describir tanto el desa- 
rrollo de estas notaciones como la comunicación que 
tiene lugar entre ellas. De la misma manera que desa- 
rrolló esta notación, también desarrolló una serie de 
leyes algebraicas que permiten llevar a cabo un razo- 
namiento: por ejemplo, sus leyes permiten al dise- 
ñador demostrar que el proceso P,no se bloqueará 
esperando la acción de otro proceso P,que está a su 
vez esperando a que el proceso P, lleve a cabo algu- 
na otra acción. 

La notación PSI es muy simple en comparación con 
una notación Z u Object Z; depende del concepto de un 
suceso. Un suceso es algo que se puede observar, es ató- 
mico e instantáneo, lo que significa que un suceso, por 
ejemplo, no se puede interrumpir, sino que se comple- 
tará, independientemente de lo que esté ocurriendo en 
un sistema. La colección de sucesos asociados con algún 
proceso P se conoce como el alfabeto de P y se escribe 
como CP. Ejemplos típicos de sucesos son el encendi- 
do de la válvula de un controlador industrial, la actua- 
lización de una variable global de un programa o la 
transferencia de datos a otra computadora. Los proce- 
sos se definen recursivamente en función de los suce- 
sos. Por ejemplo 


(e =P) 


describe el hecho de que un proceso está involucrado 
en el suceso e dentro de AP y entonces se comporta 
como P. En PSI se pueden anidar definiciones de pro- 
cesos: por ejemplo, P se puede definir en función de 
otro proceso P, como 


(e > (e, >P,)) 


en donde ocurre el suceso e, y el proceso se comporta 
como el proceso P,. 

La funciones que se acaban de describir no son muy 
útiles, ya que no proporcionan ninguna opción, por ejem- 
plo, para el hecho de que un proceso se pueda encargar 
de dos sucesos. El operador de opción | permite que las 
especificaciones PSI incluyan el elemento de determi- 
nismo. Por ejemplo, la siguiente especificación define 
un proceso P que permite una opción. 


P= (e, >Ple,> P,) 


Aquí el proceso P se define como un proceso capaz 
de encargarse de dos sucesos e, o e, Si se da el prime- 
ro, el proceso se comportará como P,, y si aparece el 
segundo, se comportará como P,. 

En PSI existe una serie de procesos estándar. PARAR 
es el proceso que indica que el sistema ha terminado de 
manera anormal, en un estado no deseado como es el 
bloqueo. SALTAR es un proceso que termina satisfac- 
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toriamente. EJECUTAR es un proceso que puede encar- 
garse de cualquier suceso en su alfabeto. Al igual que 
PARAR es un proceso no deseado e indica que ha habi- 
do un bloqueo. 

Para poder hacemos una idea de la utilización de PSI 
en la especificación de procesos especificaremos algu- 
nos sistemas muy simples. El primero es un sistema que 
se compone de un proceso C, Una vez que se ha acti- 
vado este proceso, la válvula de un reactor químico se 
cerrará y se parará. 


aC = (cerrar) 
C= (cerrar-> PARAR) 


La primera línea define el alfabeto del proceso como 
un proceso que se compone de un suceso, y la segunda 
línea establece que el proceso € se encargará de cerrar 
y entonces parar. 

Esta es una especificación muy simple y algo irreal. 
Definamos ahora otro proceso C, que abrirá la válvula, 
la cerrará y que comenzará otra vez a comportarseenton- 
ces como C.,. 


aC, = 
Cj= 


Una definición alternativa donde se definan dos pro- 
cesos sería 


Labrir, cerrar) 
(abrir—= cerrar > C,) 


OC, = Labrir) 
Cs (abrir=> C,) 
Y 
OC, = (cerrar) 
C, == (cerrar=> C,) 


Aquí, el primer proceso €, tiene el alfabeto fabrir), 
se encarga de un solo suceso que aparece dentro del alfa- 
beto y que se comporta entonces como el proceso C.. 
El C, también posee un alfabeto de un solo suceso, se 
encarga de este suceso y se comporta entonces como 
C,. Un observador ajeno al tema que vea el sistema 
expresado de esta forma vería la siguiente sucesión de 
SUCESOS: 


abrir, cerrar, abrir, cerrar.. .. 


Esta sucesión se conoce como rastreo del proceso. 
A continuación, se muestra otro ejemplo de especifica- 
ción PSI. Esta representa un robot que se puede encar- 
gar de dos sucesos que se corresponden con un retroceso 
o un avance en la línea. Se puede establecer la defini- 
ción del camino infinito de un robot sin puntos finales 
en el recorrido de la siguiente manera 


AROBOT = favance, retroceso] 
ROBOT =(avance> ROBOT! retroceso >ROBOT) 


Aquí el robot se puede encargar de avanzar O retro- 
ceder y comportarse como un robot, pudiendo avanzar 
y retroceder, y así sucesivamente. Supongamos otra vez 
que la especificación es real introduciendo algunas otras 
funciones PSI. La complicación es que la pista sobre la 
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que viaja el robot se compone de cientos de movimientos 
con avances y retrocesos que denotan este movimien- 
to. Supongamostambién que en esta pista el robot arran- 
ca de la posición 1. A continuación se muestra la 
definición de este ROBOT, : 


AROBOT. = [avance,retroceso) 
ROBOT, = R, 
R, = (avance >R,) 
R; = (avance > R,,) retroceso —>R, 0 
(¿<100A ¡> 1) 
Rio = (retroceso > R,,) 


Aquí el robot representa un proceso con los mismos 
dos sucesos del alfabeto como el robot anterior. Sin 
embargo, la especificación de su implicación en estos 
sucesoses más compleja. La segunda línea estableceque 
el robot arrancará en una posición inicial y se compor- 
tará de la misma manera que con el proceso R, el cual 
representa su posición en el primer recuadro. La terce- 
ra línea establece que el proceso R, solo se puede encar- 
gardel suceso de avance ya que se encuentra en el punto 
final. La cuarta línea define la serie de procesos desde 
R, aR,,. Aquí se defineel hecho de que en cualquierpun- 
to el robot se puede avanzar o retroceder. La línea final 
especifica lo que sucede cuando el robot ha alcanzado 
el final del recorrido: solo puede retroceder. 

Esta es la manera en que funcionan los procesos en 
PSI. En sistemas reales existirá una serie de procesos 
ejecutándose concurrentemente y comunicándose con 
otros, como se muestra a continuación mediante algu- 
nos ejemplos: 

e En un sistema cliente/servidor, un solo servidor en 
ejecución como proceso estará en comunicación con 
varios clientes que igualmente se ejecutarán como 
procesos. 

En sistemas de tiempo real, que controlan un reac- 
tor químico, existirán procesos de supervisión de la 
temperatura de los reactores que se comunicarán con 
los procesos que abren y cierran las válvulas de estos 
reactores. 

En un sistema de control de tráfico aéreo, la funcio- 
nalidad del radar se podría implementar como pro- 
cesos que se comunican con procesos que llevan a 
cabo las tareas de visualizar en pantalla las posicio- 
nes de las aeronaves. 


De aquí que exista la necesidad de representaren PSI 
la ejecución en paralelo de los procesos. También exis- 
te la necesidad de algún medio con el que se produzca 
la comunicación y la sincronización entre estos proce- 
sos. El operador que especifica la ejecución en parale- 
lo en PST es !l, Por tanto, el proceso P que representa la 
ejecución en paralelo de los procesos de P, y P, se defi- 
ne como 


P =PIP, 


La sincronización entre los procesos se logra median- 
te procesos con algún solapamientoen sus alfabetos. La 
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norma sobre la comunicación y la sincronización es que 
cuando dos procesos se están ejecutando en paralelo, don- 
de tienen algunos sucesos en común, deben de ejecutar 
ese suceso simultáneamente. Tomemos como ejemplo un 
sistema bastante simple y real que enciende y apaga las 
luces y que se basa en un ejemplo similar al de [HIN9S5]. 
Las definiciones de los dos procesos de este sistema son: 


aLUZ, = fencendida,apagada] 

LUZ, = (encendida > encendida —> PARAR 
l apagada > apagada —> PARAR) 

aLUZ, = (encendida, apagada) 

LUZ, = (encendida —> apagada -+LUZ,) 


Ambos procesos tienen el mismo alfabeto. El primer 
proceso LUZ,,o bien enciende la luz y la vuelve a encen- 
der de nuevo (hay que recordar que es posible que otros 
procesos hayan apagado el sistema entre medias, y se 
ha averiado (PARAR es un estado no deseado), o bien 
la apaga una vez, y una vez más. El proceso LUZ, 
enciende la luz y la apaga, y a continuación empieza a 
comportarse de nuevo como LUZ,. Los dos procesos en 
paralelo se denotan mediante: 


LUZ, LUZ, 


¿Cuál es el efecto de ejecutar estos procesos en para- 
lelo? En una introducción como es esta no se puede 
entrar en mucho detalle. Sin embargo, se puede dar una 
idea del razonamiento que se puede aplicar a dicha 
expresión. Se recordará que cuando se introdujo PSI se 
afirmó que no solo consiste en una notación para espe- 
cificarlos procesos concurrentes, sino que también con- 
tiene una serie de normas que permiten razonar a cerca 
de las expresiones de procesos complejos y, por ejem- 
plo, determinar si cualquier suceso nefasto como un blo- 
queo aparecerá dentro del sistema especificado en PSI. 
Para poder ver lo que ocurre merece la pena aplicar algu- 
nas de las normas que desarrolló Hoare para PSI. Recor- 
demos que se intenta averiguar cuál es el proceso que 
se ha definido mediante la ejecución en paralelo de los 
procesos LUZ, y LUZ,. Esta expresión es equivalente a: 


LUZ, a > encendido -+PARAR 
= apagado > apagado > PARAR) 
LUZ, =  (encendido-+ apagado —> LUZ.) 


Una de las normas de Hoare establece que 
(e +P)ll(e > 0) =e > (PIO) 
.Esto nos permite ampliar la expresión que involucra 
a LUZ, y LUZ, con 


(encendido > ((encendido> PARAR) (apagado > 
LUZ) 


Esta expresión se puede simplificar aun más utili- 
zando otra de las normas de Hoare a la expresión 


(encendido -+PARAR) 


lo cual significa que la ejecución en paralelo de los dos 
procesos es equivalente a una luz que se enciende y 
entonces se para en un estado de bloqueo no deseado. 
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Hasta ahora, se han visto procesos que cooperan con 
la sincronización mediante el hecho de que tienen alfa- 
betos similares o que se solapan. En los sistemas reales 
también existirá la necesidad de que los procesos se 
comuniquen con datos. PSI es un método uniforme para 
la comunicación de datos: se trata simplemente como 
un suceso en donde el suceso 1omCanal.val indica que 
ha ocurrido un suceso que se corresponde con la comu- 
nicación del valor val a través de un canal nomCanal, 
PSI contiene un dispositivo notacional similar al de Z 
para distinguir entre la entrada y la salida; para distin- 
guir la primera se introduce el signo de interrogación, 
mientras que para distinguir la segunda se utiliza el sig- 
no de exclamación. 

A continuación, se muestra un ejemplo basado en 
[HIN95], en donde se representa la especificación de un 
proceso que toma dos enteros y forma el producto. 


= (en?x—>A,,,) 
(en? Y > A...) 


0) 
(fueral(x x y) >A,,,) 


ro) 


Aprimera vista esto parece muy complicado, por eso 
merece la pena describirlo línea a línea. La primera defi- 
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ne el proceso PROD,, el cual equipara este proceso con 
A, sin entradas esperando. La segunda línea establece 
que cuando el proceso recibe un valor de entrada x se 
comporta como el proceso con un valor x almacenado. 
La tercera línea establece que cuando un proceso con 
un valor almacenadorecibe un valor y entonces se com- 
porta como un proceso con dos valores almacenados. 
La última línea establece que un proceso con dos valo- 
res almacenados emitirá el producto de estos valores, 
almacenará el último valor y entonces se comportará 
como Á con ese valor almacenado, de manera que, por 
ejemplo, si aparece otro valor se multiplicará por ese 
valor y se emitirá por el canal de salida. Así pues, la 
especificación anterior se comporta como un proceso 
en donde se recibe una sucesión de enteros y lleva a 
cabo la multiplicación de los valores. 

Se puede decir entonces que esta es una definición 
breve de PSI —al igual que todos los métodos formales 
incluye también una notación matemática y las normas 
para el razonamiento—. Aunque en las descripciones de 
Z y Object Z no se han examinado las normas y se ha 
concentrado en el formalismo todavía contienen fun- 
ciones sustanciales para razonar sobre las propiedades 
de un sistema. 


La decisión de hacer uso de los métodos formales en el 
mundo real no debe de adoptarse a la ligera. Bowen y 
Hinchley [BOW95] han acuñado «los diez manda- 
mientos de los métodos formales»,como guía para aque- 
llos que estén a punto de embarcarse en este importante 
enfoque de la ingeniería del software”. 


Cons) 


la decisión de utilizar métodos formales no debería 
tomarse a lo ligera. Siga estos «mandamientos» 

y asegúrese de que todo el mundo haya recibida 

lo formación adecuada. 


1. Seleccionarás la notación adecuada. Con objeto 
de seleccionar eficientemente dentro de la amplia 
gama de lenguajes de especificación formal exis- 
tente, el ingeniero del software deberá considerar 
el vocabulario del lenguaje, el tipo de aplicación 
que haya que especificar y el grado de utilización 
del lenguaje. 

11. Formalizarás, pero no de más. En general, resulta 
necesario aplicar los métodos formales a todos los 
aspectos de los sistemas de cierta envergadura. 
Aquellos componentes que sean críticos para la 


5 Esta descripción es una versión sumamente abreviada de [BOW95]. 


seguridad serán nuestras primeras opciones, e irán 
seguidos por aquellos componentes cuyo fallo no 
se pueda admitir (por razones de negocios). 


111. Estimarás los costes. Los métodos formales tienen 
unos costes de arranque considerables. El entrena- 
miento del personal, la adquisición de herramien- 
tas de apoyo y la utilización de asesores bajo 
contrato dan lugar a unos costes elevados en la pri- 
mera ocasión. Estos costes deben tenerse en cuenta 
cuando se esté considerando el beneficio obtenido 
frente a esa inversión asociada a los métodos for- 
males. 


IV. Poseerás un experto en métodos formales a tu 
disposición. El entrenamiento de expertos y la ase- 
soría continua son esenciales para el éxito cuando 
se utilizan los métodos formales por primera vez. 


V, No abandonarás tus métodos formales de desa- 
rrollo. Es posible, y en muchos casos resulta desea- 
ble, integrar los métodos formales con los métodos 
convencionales y/o con métodos orientados a obje- 
tos (Capítulos 12 y 21). Cada uno de estos métodos 
posee sus ventajas y sus inconvenientes. Una com- 
binación de ambos, aplicada de forma adecuada, 
puede producir excelentes resultados”. 


6 La ingeniería del software de la sala limpia (Capítulo26) es un ejem- 
plo integrado que hace uso de los métodos formales y de una nota- 
ción más convencional para el desarrollo.. 
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Referencia 


Información útil sobre los métodos formales se puede 
obtener en: www.clcam/users/mgh1001 


VL Documentarás suficientemente. Los métodos 
formales proporcionan un método conciso, sin 
ambigiedades y consistente para documentar los 
requisitos del sistema. Sin embargo, se recomienda 
que se adjunte un comentario en lenguaje natural 
a la especificación formal, para que sirva como 
mecanismo para reforzar la comprensión del sis- 
tema por parte de los lectores. 

VI. No comprometerás los estándares de calidad. 
«Los métodos formales no tienen nada de mágico» 
[BOW94], y, por esta razón, las demás activida- 
des de SQA (Capítulo 8) deben de seguir apli- 
cándose cuando se desarrollen sistemas. 


VII.No serás dogmático. El ingeniero de software 
debe reconocer que los métodos formales no son 


una garantía de corrección. Es posible (o como 
algunos probablemente dirían) que el sistemafinal, 
aun cuando se haya desarrolladoempleando méto- 
dos formales, siga conteniendo pequeñas omisio- 
nes, errores de menor importancia y otros atributos 
que no satisfagan nuestras expectativas. 


IX. Comprobarás, comprobarásy volverás a com- 
probar. La importancia de la comprobación del 
software se ha descrito en los Capítulos 17, 18 
y 23. Los métodos formales no absuelven al inge- 
niero del software de la necesidad de llevar a 
cabo unas comprobaciones exhaustivas y bien 
planeadas. 


X. —Reutilizarás cuanto puedas. A la larga, la única 
forma racional de reducir los costes del software 
y de incrementar la calidad del software pasa por 
la reutilización (Capítulo 27). Los métodos for- 
males no modifican esta realidad. De hecho, qui- 
zás suceda que los métodos formales sean un 
enfoque adecuado cuando es preciso crear com- 
ponentes para bibliotecas reutilizables. 


Aun cuando las técnicas de especificación formal, con 
fundamento matemático, todavía no se utilizan con 
demasiada frecuencia en la industria)éstas ofrecen cier- 
tamente unas ventajas substanciales con respecto a las 
técnicas menos formales. Liskov y Bersins [LIS86] 
resumen esto en la manera siguiente: 


Las especificaciones formales se pueden estudiar mate- 
máticamente, mientras que las especificaciones informales 
no pueden estudiarse de esta manera. Por ejemplo, se puede 
demostrar que un programa correcto satisface sus especifi- 
caciones, o bien se puede demostrar que dos conjuntos alter- 
nativos de especificacionesson equivalentes... Ciertas formas 
de falta de completitud o de inconsistencia se pueden detec- 
tar de forma automática. 


Además, la especificación formal elimina la ambi- 
gitedad, y propugna un mayor rigor en las primeras fases 
del proceso de ingeniería del software. 


Pero siguen existiendo problemas. La especificación 
formal se centra fundamentalmente en las funciones y 
los datos. La temporización, el control y los aspectos de 
comportamiento del problema son más difíciles de repre- 
sentar. Además, existen ciertas partes del problema (por 
ejemplo, las interfaces hombre-máquina) que se especi- 
fican mejor empleando técnicas gráficas. Por último, la 
especificación mediante métodos formales es más difí- 
cil de aprender que otros métodos de análisis que se pre- 
sentan en este libro y representa «un choque cultural)) 
significativopara algunos especialistas del software. Por 
esta razón, es probable que las técnicas de especifica- 
ción formales matemáticas pasen a ser el fundamento de 
una futura generación de herramientas CASE. Cuando 
esto suceda, es posible que las especificaciones basadas 
en matemáticas sean adoptadas por un segmento más 
amplio de la comunidad de la ingeniería del software”. 


Los métodos formales ofrecen un fundamento para entor- 
nos de especificación que dan lugar a modelos de análi- 
sis más completos, consistentes y carentes de ambigiiedad, 
que aquellos que se producen empleando métodos con- 
vencionales u orientados a objetos. Las capacidadesdes- 


criptivas de la teoría de conjuntos y de la notación lógi- 
ca capacitan al ingeniero del software para crear un enun- 
ciado claro de los hechos (requisitos). 

Los conceptos subyacentes que gobiernan los méto- 
dos formales son: (1) los invariantes de datos-con- 


7 Es importante tener en cuenta que hay otras personas que no están 
de acuerdo. Véase [YOU94]. 
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diciones que son ciertas a lo largo de la ejecución del 
sistema que contiene una colección de datos—; (2) el 
estado —los datos almacenados a los que accede el 
sistema y que son alterados por él —= (3) la operación 
—na acción que tiene lugar en un sistema y que lee 
o escribe datos en un estado —. Una operación queda 
asociada con dos condiciones: una precondición y una 
postcondición. 

La matemática discreta —la notación y práctica aso- 
ciada a los conjuntos y a la especificación constructiva, 
a los operadores de conjuntos, a los operadores lógicos 
y alas sucesiones —constituyen la base de los métodos 
formales. Estas matemáticas están implementadas en el 
contexto de un lenguaje de especificación formal, tal 
como Z. 


ÍTULO 25 MÉTODOS FORMALES 


Z, al igual que todos los lenguajes de especificación 
formal, posee tanto un dominio semántico como un 
dominio sintáctico. El dominio sintáctico utiliza una sim- 
bología que sigue estrechamente a la notación de con- 
juntos y al cálculo de predicados. El dominio semántico 
capacita al lenguaje para expresar requisitos de forma 
concisa. La estructura Z contiene esquemas, estructuras 
en forma de cuadro que presentan las variables y que 
especifican las relaciones entre estas variables. 

La decisión de utilizar métodos formales debe con- 
siderar los costes de arranque, así como los cambios pun- 
tuales asociados a una tecnología radicalmente distinta. 
En la mayoría de los casos, los métodos formales ofre- 
cen los mayores beneficios para los sistemas de seguri- 
dad y para los sistemas críticos para los negocios. 


[BOW95] Bowan, J.P., y M.G. Hinchley, «Ten Command- 
ments of Fermal Methods, Computer», vol, 28, 1.24, Abril 
1995. 


[GRI93] Gries, D., y F.B, Schneider, A Logical Approach to 
Discrete Math, Springer-Verlag, 1993. 


[GUT93] Guttag, J.V., y J.J. Horning, Larch: Languages and 
Toolsfor Formal Specifications, Springer-Verlag, 1993. 


[HAL90] Hall, A., «Seven Myths of Formal Methods», IEEE 
Software, Septiembre 1990. 


[HOR85] Hoare, C.A.R., Communicating Sequential Pro- 
cesses, Prentice-Hall International, 1985. 


[HIN95] Hinchley, M.G., y S.A. Jarvis, ConcurrentSystems: 
Formal Development in CSP, McGraw-Hill, 1995, 


[JON91] Jones, C.B., Systematic Development Using VDM, 
2.* ed., Prentice-Hall, 1991. 


[LIS86] Liskov, B.H., y V. Berzins, «An Appraisal of Pro- 
gram Specifications», publicado en Software Specifica- 


tions Techniques; eds.: N. Gehani y A.T. McKittrick, Addi- 
son-Wesley, 1986, p. 3. 

[MAR94] Marcianiak, J.J. (ed.), Encyclopedia of Software 
Engineering, Wiley, 1994. 

[ROS95] Rosen, K.H., Discrete Mathernatics and lts Appli- 
cations, 3.2 ed., McGraw-Hill, 1995. 

[SPI88] Spievy, J.M., Understanding Z: A Specification Lan- 
guage and lts Formal Semantics, Cambridge University 
Press, 1988. 


[SPI92] Spievy, J.M., The Z Notation: A Reference Manual, 
Prentice-Hall, 1992. 

[WIL87] Witala, S.A., Discrete Mathematics: A Unified 
Approach, McGraw-Hill, 1987. 

[WIN90] Wing, J.M., «A Specifter*s Introduction to Formal 
Methods», JEEE Computer, vol. 23, n.? 9, Septiembre 
1990, pp. 8-24. 


[YOU94] Yourdon, E., «Formal Methods», Guerrilla Pro- 
grammer, Cutter Information Corp., Octubre 1994, 


25.1. Revisar los tipos de deficiencias asociados a los enfo- 
ques menos formales de la ingeniería del software en la Sec- 
ción 25.1.1. Proporcione tres ejemplos de cada uno de ellos, 
procedentes de su propia experiencia. 


25.2. Los beneficios de las matemáticas como mecanismo de 
especificación se han descrito con cierta extensión en este capí- 
tulo. ¿Existe algún aspecto negativo? 


25.3. Se le ha asignado un equipo de software que va a desa- 
rrollar software para un fax módem. Su trabajo consiste en 
desarrollar el «listín telefónico» de la aplicación. La función 
del listín telefónico admite hasta MaxNombre nombres de 
direcciones que serán almacenados junto con los nombres de 
la compañía, números de fax y otras informaciones relacio- 
nadas. Empleando el lenguaje natural, defina: 


AZ 


a. el invariante de datos 
b. el estado 
e. las operaciones probables 


25.4. Se le ha asignado un equipo de software que está desa- 
rrollando software, denominado DuplicadosMemoria, y que 
proporciona una mayor cantidad de memoria aparente para 
un PC, en comparación con la memoria física. Esto se logra 
identificando, recogiendo y reasignando bloques de memo- 
ria que hayan sido asignados a aplicaciones existentes pero 
no estén siendo utilizados. Los bloques no utilizados se rea- 
signan a aplicaciones que requieran memoria adicional. Efec- 
tuando las suposiciones oportunas, y empleando el lenguaje 
natural, defina: 
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a. el invariante de datos 
b. el estado 
c. las operaciones probables 


25.5. Desarrollar una especificación constructiva para un con- 
junto que contenga tuplas de números naturales de la forma 
(x, y, 22) tales que la suma de x e y es igual az. 


25.6. El instalador de una aplicación basada en PC determi- 
na si está presente o no un conjunto de recursos de hardware 
y software adecuados. Comprueba la configuración de hard- 
ware para determinar si están presentes o no diferentes dis- 
positivos (de entre muchos dispositivos posibles) y determina 
si ya están instaladas las versiones específicas de software del 
sistema y de controladores. ¿Qué conjunto de operadores se 
utilizaría para lograr esto? Proporcionar un ejemplo en este 
contexto. 


25.7. Intente desarrollar una expresión empleando la lógica y 
un conjunto de operadores para la siguiente sentencia: «Para 
todo X e y, six es padre de y e y es padre de z, entonces x es 
abuelo de z. Todas las personas tienen un padre.» Pista: utili- 
ce las funciones P(x, y ) y Gx, z) para representar las funcio- 
nes padre y abuelo, respectivamente. 


25.8. Desarrollar una especificación constructiva de conjun- 
tos correspondiente al conjunto de parejas en las cuales el pri- 
mer elemento de cada pareja es la suma de dos números 
naturales no nulos, y el segundo elemento es la diferencia de 
esos dos números. Ambos números deben de estar entre 100 
y 200 inclusive. 


25.9. Desarrollar una descripción matemática del estado y del 
invariante de datos para el Problema 25.3. Refinar esta des- 
cripción en el lenguaje de especificación Z. 


25.10. Desarrollar una descripción matemática del estado y 
del invariante de datos para el Problema 25.4. Refinar esta des- 
cripción en el lenguaje de especificación Z. 


25.11. Utilizando la notación Z presentada en la Tabla 25.1, 
seleccionar alguna parte deP sistema de seguridad HogarSe- 
guro descrito anteriormente en este libro, e intentar especifi- 
carlo empleando Z. 


25.12. Empleando una o más de las fuentes de información 
indicadas en las referencias de este capítulo o en la sección 
de Otras Lecturas y Fuentes de Información, desarrollar una 
presentación de media hora acerca de la sintaxis y semán- 
tica básica de un lenguaje de especificación formal y dis- 
tinto de Z. 


Además de los libros utilizados comoreferencia en este capí- 
tulo, se ha publicado un número bastante grande de libros 
acerca de temas relacionados con los métodos formales a lo 
largo de los últimos años. Se presenta a continuación un lis- 
tado de los ejemplos más significativos: 


Bowan, J., Formal Specification and Documentation using 
Z: A Case study Approach, International Thomson Compu- 
ter Press, 1996. 

Casey, C., A Programming Approach to Formal Methods, 
McGraw-Hill, 2000. 

Cooper, D., y R, Barden, Z in Practice, Prentice-Hall, 1995. 

Craigen, D., S. Gerhart y T. Raltson, Industrial Applica- 
tion of Formal Methods to Model, Design, Diagnose and Ana- 
lize Computer Systems, Noyes Data Corp., Park Ridge, NJ, 
1995. 

Diller, A.,Z.: An Introduction to Formal Methods, 2.2 ed., 
Wiley, 1994, 

Harry, A., Formal Methods Fact File: VDM y Z, Wiley, 
1997 

Hinchley, M., y J. Bowan, Applications of Formal Methods, 
Prentice-Hall, 1995. 

Hinchley, M., y J, Bowan, Industrial Strength Formal 
Methods, Academic Press, 1997. 

Hussmann, H., Formal Foundations for Software Engi- 
neering Methods, Springer-Verlag, 1997. 
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Jacky, J., The Way of Z: Practical Programming With For- 
mal Methods, Cambridge University Press, 1997. 

Lano, J., y Haughton (eds.), Object-Oriented Specifica- 
tion Case Studies, Prentice-Hall, 1993. 

Rann, D., J. Turner y J. Whitworth, Z:A Beginner's Guide, 
Chapman « Hall, 1994. 

Ratcliff, B., Introducing Specification Using Z: A Practi- 
cal Case Study Approach, McGraw-Hill, 1994. 

D, Sheppard, An Introduction to Formal Specification with 
Z and VDM, McGraw-Hill, 1995. 


Los ejemplos de septiembre de 1990 de IEEE Transac- 
tions on Software Engineering, IEEE Software e IEEE Com- 
puter estaban dedicados todos ellos a los métodos formales. 
Siguen siendo una fuente excelente de información Útil. 

Schuman ha editado un libro que describe los métodos 
formales y las tecnologías orientadas a objetos (Formal 
Object-Oriented Development, Springer-Verlag, 1996). El 
libro ofrece líneas generales acerca de la utilización selecti- 
va de métodos formales y acerca de la forma en que estos 
métodos se pueden utilizar en conjunción con enfoques OO. 

En Internet se encuentra una gran cantidad de informa- 
ción acerca de los métodos formales y de otros temas rela- 
cionados. En http://www.pressmanS,com se puede encontrar 
una lista de referencias actualizada relevante para los méto- 
dos formales. 
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INGENIERÍA DEL SOFTWARE 
DE SALA LIMPIA 


CAPÍTULO 
A utilización integrada del modelado de ingeniería del software convencional, métodos 
formales, verificación de programas (demostraciones de corrección) y estadística SQA 
se han combinado en una técnica que puede dar lugar a un software de calidad extre- 
madamente alta. La ingeniería del software de sala limpia es un enfoque que hace hincapié en 
la necesidad de incluir la corrección en el software a medida que éste se desarrolla. En lugar 
del ciclo clásico de análisis, diseño, pruebas y depuración, el enfoque de sala limpia sugiere un 
punto de vista distinto [LIN94]: 


La filosofía que subyace tras la ingeniería del software de sala limpia consiste en evitar la dependencia 
de costosos procesos de eliminación de defectos, mediante la escritura de incrementos de código desde un 
primer momento, y mediante la verificación de su corrección antes de las pruebas. Su modelo de proceso 
incluye la certificación estadística de calidad de los incrementos de código, a medida que estos se van aña- 
diendo cn el sistema. 


En muchos aspectos, el enfoque de sala limpia eleva la ingeniería del software a otro nivel: 
Al igual que las técnicas de métodos formales que se presentaban en el Capítulo 25, el pro= 
ceso de sala limpia hace hincapié en el rigor en la especificación y en el diseño, y en la veri- 
ficación formal de cada uno de los elementos del modelo de diseño resultante mediante;el 
uso de pruebas de corrección basadas en fundamentos matemáticos. Al extender el enfoque 
adoptado en los métodos formales, el enfoque de sala limpia hace hincapié también en téc- 
nicas de control estadístico de calidad, incluyendo las comprobaciones basadas en el uso anti- 
cipado del software por parte de los clientes. 


VISTAZO RÁPIDO 


¿Qué es? ¿Cuántas veces se ha oído decir 


«Hazlo correctamente a la primera.? Esa 
es la filosofía primordial de la ingenie- 
ría del software de sala limpia, un pro- 
ceso queda importancia ala verificación 
matemática delacorrecciónantes de que 
comience la construcción de un progra- 
ma y de quela certificación dela fiabili- 
dad del software forme parte de la 
actividad de pruebas. Haciendo hinca- 
pié en una filosofía más profunda, setra- 
taría de aquella quetiene índices de fallo 
extremadamente bajos y que es dificil o 
imposible de lograr utilizando métodos 
menos formales. 


¿Quién lo hace? Un ingeniero del soft- 


ware formado para esta especialización. 


¿Por qué es importante? Los errores 


conllevan doble trabajo. Trabajar el 
doble lleva más tiempo y es más caro. 
¿No sería maravilloso poder reducir dra- 
máticamente la cantidad de errores 


(fallosinformáticos)que se cometen en 
el diseño y construcción del software? 
Esto es lo que promete laingeniería del 
softwarede sala limpia. 


¿Cuáles son los pasos? Los modelos de 


análisis y diseño secreanutilizando la 
representación de estructura de caja. 
Una «caja» encapsula el sistema (o 
algún aspecto del sistema) a un nivel 
específico de abstracción. La verifica- 
ción de la corrección se aplica una vez 
que se ha completado el diseño de la 
estructurade caja Y la prueba estadís- 
tica de la utilización comienza una vez 
que se ha verificado la corrección en 
cada estructura de caja. El software se 
prueba definiendo un conjunto de esce- 
narios, determinando la probabilidad 
deutilización decada uno y definiendo 
entonces las pruebas aleatorias que se 
ajustan a las probabilidades. Por últi- 
mo, los registros de errores resultantes 


se analizan para permitir el cálculo 
matemático de la fiabilidad proyectada 
en el componente de software. 


¿Cuál es el producto obtenido? El 


desarrollo de especificaciones de caja 
negra, de caja de estado y de caja lim- 
pia. Y, además, el registro de los resul- 
tados de las pruebas formales de 
corrección y las pruebas estadísticas 
de utilización. 


¿Cómo puedo estar seguro de que 


lo he hecho correctamente? La 
prueba formal de corrección se aplica 
a la especificación de estructura de 
cajas. Las pruebas estadísticas de uti- 
lización ejercitan los escenarios de uti- 
lización para asegurar que no se 
revelen y se puedan corregir los erro- 
resenla funcionalidad del usuario. Los 
datos de prueba se utilizan para pro- 
porcionar una señal de la fiabilidad del 
software. 


Cuando el software falla en el mundo real, suelen abundar los peligros a largo plazo así como 
los peligros inmediatos. Los peligros pueden estar relacionados con la seguridad humana, con 
pérdidas económicas o con el funcionamiento efectivo de una infraestructura social y de nego- 
cios. La ingeniería del software de sala limpia es un modelo de proceso que elimina los defec- 
tos antes de que puedan dar lugar a riesgos graves. 
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26.1 EL ENFOQUE DE SALA LIMPIA 


La filosofía de la «sala limpian en las técnicas de fabri- 
cación de hardware es en realidad algo bastante senci- 
llo: se trata de una forma rentable y eficiente, en términos 
de tiempo, de establecer un enfoque de fabricación que 
impida la introducción de defectos de producción. En 
lugar de fabricar un producto y dedicarse después a eli- 
minar defectos, el enfoque de sala limpia demanda la 
disciplina necesaria para eliminar errores en las espe- 
cificaciones y en el diseño, fabricando entonces el pro- 
ducto de forma «limpia». 


¡geniería de sala limpia logra control de calidad 
sobre el desarrollo del software 
estrictamente el proceso del diseño 
roceso de comprobación en un cauce 

lesarrollo incremental. de software. 


La filosofía de sala limpia fue propuesta por prime- 
ra vez para la ingeniería del software por parte de Mills 
y sus colegas [WIL87] durante los años 80. Aun cuan- 
do las primeras experiencias acerca de este enfoque dis- 
ciplinado para los trabajos relacionados con el software 
mostraba promesas significativas [HAU94], no ha alcan- 
zado una amplia utilización. Henderson [HEN95] sugie- 
re tres posibles razones: 


1. La creencia en que la metodología de sala limpia es 
excesivamente teórica, excesivamente matemática y 
excesivamente radical para utilizarla en el desarro- 
llo de software real. 


2. No propugna una comprobación unitaria por parte 
de los desarrolladores, sino que la sustituye por una 
verificación de la corrección y por un control esta- 
dístico de la calidad —.estos conceptos que repre- 
sentan una desviación fundamental con respecto a la 
forma en que se desarrolla la mayor parte del soft- 
ware en la actualidad —. 


3. La madurez de la industria de desarrollo del soft- 
ware. El uso de procesos de sala limpia requiere 
una aplicación rigurosa de procesos definidos en 
todas las fases del ciclo de vida. Dado que la mayor 
parte de la industria funciona todavía en el nivel 
ad hoc (según se ha definido por parte del Software 
Engineering Institute Capability Maturity Model), 
la industria no ha estado preparada para aplicar 
estas técnicas. 


Aun cuando existen ciertos indicios de verdad en 
todas las indicaciones expresadas anteriormente, los 
posibles beneficios de la ingeniería del software de sala 
limpia compensan más que sobradamente la inversión 
requerida para superar la resistencia cultural que se 
encuentra en el núcleo de estas objeciones. 
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26.1.1. La estrategia de sala limpia 


El enfoque de sala limpia hace uso de una versión espe- 
cializada del modelo incremental de software (Capítu- 
lo 2). Se desarrolla un «cauce de incrementos de software» 
[LIN94] por parte de equipos de ingeniería del software 
pequeños e independientes. A medida que se va certifi- 
cando cada incremento, se integra en el todo. Consi- 
guientemente, la funcionalidad del sistema va creciendo 
con el tiempo. 


¿Cuáles son las tareas 
principales que se realizan 
en la ingeniería del software 
de sala limpia? 


La sucesión de tareas de sala limpia para cada incre- 
mento se ilustra en la Figura 26.1. Los requisitos glo- 
bales del sistema o producto se van desarrollando 
empleando los métodos de ingeniería de sistemas des- 
critos en el Capítulo 10. Una vez que se ha asignado 
una funcionalidad al elemento de software del sistema, 
el tubo de la sala limpia comienza sus incrementos. Se 
producen las tareas siguientes: 


Planificación de incrementos.Se desarrolla un plan 
de proyecto que adopta la estrategia incremental. Se van 
estableciendo las funcionalidades de cada uno de los 
incrementos, su tamaño estimado y un plan de desarro- 
llo de sala limpia. Es preciso tener especial cuidado para 
asegurar que los incrementos certificados se vayan inte- 
grando de forma temporalmente oportuna. 


Recolección de requisitos. Mediante el uso de téc- 
nicas similares a las presentadas en el Capítulo 11, se 
desarrolla una descripción más detallada de requisitos 
del nivel del usuario (para cada incremento). 


Especificación de la estructura de cajas. Se utiliza un 
método de especificación que hace uso de estructuras de 
caja [HEV93] para describir la especificación funcional. 


incremento n? 1 


O a 


incremento n* 2 


qer+ccapg 


incremento n* 3 


Mp esc p 


IS a ligebiéia de sistemas GC  - Generación de código 

RR - Recolección de requisitos IC. - Inspección de código 

EEC -+ Especificación de estructura CEU - Comprobación estadística 
de cajas de utilización 

DF  - Diseñoformal C - Certificación 


VC Verificación de corrección PP. -Planificación de prueba 


FIGURA 26.1. El modelo de proceso de sala limpia. 
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Ajustado a los principios de análisis operacional des- 
critos en el Capítulo 11, la estructura de caja «aísla y 
separa la definición creativa del comportamiento, de los 
datos, y de los procedimientos para cada nivel de refi- 
namiento», 


Referencia Web 
Uno fuente excelente de información y de recursos 
poro la ingeniería del software de sala limpio 

se puede entontror en www.tleansoft.com 


Diseño formal. Mediante el uso del enfoque de 
estructura de cajas, el diseño de sala limpia es una exten- 
sión natural y sin discontinuidades de la especificación. 
Aun cuando es posible efectuar una distinción clara entre 
estas dos actividades, las especificaciones (que se deno- 
minan «cajas negras») se refinan iterativamente (den- 
tro de cada incremento) para transformarse en diseños 
análogos a la arquitectura y a los procedimientos (que 
se denominan «cajas de estado» y «cajas trasparentes», 
respectivamente). 


Verificación de corrección. El equipo de sala lim- 
pia lleva a cabo una serie de rigurosas actividades de 
verificación de corrección aplicadas primero al diseño 
y después al código. La verificación (Secciones 26.3 y 
26.4) comienza con la estructura de cajas del más alto 
nivel (la especificación) y avanza hacia el detalle de 
diseño y el código. El primer nivel de verificación de 
corrección se lleva a cabo aplicando un conjunto de 
cuestiones de corrección» [LIN88]. Si este conjunto 
de preguntas no demuestra que la especificación es 
correcta, se utilizan métodos más formales (matemáti- 
cos) de verificación. 


calidad no es una acción. Es un hábito. 


Generación de código, inspección y verificación. 
Las especificacionesde estructura de caja, que se repre- 
sentan mediante un lenguaje especializado, se traducen 
al lenguaje de programación adecuado. Se utilizan enton- 
ces técnicas estándar de recorrido o de inspección (Capí- 
tulo 8) para asegurar el cumplimiento semántico de las 
estructuras de código y de cajas, y la corrección sintác- 
tica de código. A continuación, se efectúa una verifica- 
ción de corrección para el código fuente. 


Planificación de la comprobación estadística. La 
utilización estimada del software se analiza, se plani- 
fica y se diseña un conjunto de casos de prueba que 
ejerciten la «distribución de probabilidad» de esa uti- 
lización (Sección 26.4). Según se muestra en la Figu- 
ra 26.1, esta actividad de sala limpia se realiza en 
paralelo con la especificación, la verificación y la gene- 
ración de código. 
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Consuo 


la sala limpia da importanciaa las pruebas que ejercitan 
la manera en que se utilizo realmente el sofware. 

los casos de utilización proporcionan una fuente 
excelente para el proceso de planificación estadística 

de comprobación. 


Comprobación estadística de utilización. Recor- 
dando que es imposible una comprobación exhaustiva 
del software de computadora (Capítulo 17), siempre 
resulta necesario diseñar un conjunto finito de casos de 
prueba. Las técnicas estadísticas de utilización [POO88] 
ejecutan una colección de pruebas derivadas de una 
muestra estadística (la distribución de probabilidad indi- 
cada anteriormente) de todas las posibles ejecuciones 
del programa por parte de todos los usuarios de una cier- 
ta población objetivo (Sección 26.4). 


Certificación. Una vez que se ha finalizado la veri- 
ficación, la inspección y la comprobación de utilización 
(y después de corregir todos los errores) se certifica el 
incremento como preparado para su integración. 


Al igual que otros modelos de proceso del soft- 
ware descritos en otras partes de este libro, el proce- 
so de sala limpia hace especial hincapié en la 
necesidad de conducir unos modelos de análisis y de 
diseño de muy alta calidad. Según se verá posterior- 
mente en este capítulo, la notación de estructura de 
cajas no es más que otra forma para que el ingenie- 
ro del software pueda representar los requisitos y el 
diseño. La distinción real del enfoque de sala limpia 
consiste en que se aplica la verificación formal a los 
modelos de ingeniería. 


26.1.2. ¿Qué hace diferente la sala limpia? 


Dyer [DYE92] alude a las diferencias del enfoque de 
sala limpia cuando define el proceso: 

La sala limpia representa el primer intento práctico de 
poner el proceso de desarrollo del software bajo un control 
estadístico de calidad con una estrategia bien definida para 
la mejora continua del proceso. Para alcanzar esta meta, sc 
definió un ciclo único de vida de sala limpia, que hacía hin- 
capié en una ingeniería del software basada en las matemá- 
ticas para obtener diseños de software correctos y que se 
basaba en software basado en estadística para la certifica- 
ción de fiabilidad de ese software. 


La ingeniería del software de sala limpia ditiere de 
los puntos de vista convencionales y orientados a obje- 
tos que se representan en la Partes Tercera y Cuarta de 
este libro porque: 


1. Hace uso explícito del control estadístico de calidad. 


2. Verifica la especificación del diseño empleando una 


demostración de corrección basada en las matemáticas. 

. Hace mucho uso de la comprobación estadística de 
utilización para descubrir errores de especial inci- 
dencia. 
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Y, 
CLAVE 


Las característicasmás importantes que distinguen 
la solo limpia son la comprobación de corrección 
y la comprobación estadísticade utilización. 


Evidentemente, el enfoque de sala limpia aplica la 
mayor parte, si es que no todos, de los principios bási- 
cos de ingeniería del software y de los conceptos que 
se han presentado a lo largo de este libro. Son esencia- 
les unos buenos procedimientos de análisis y diseño si 
es que se desea producir una elevada calidad. Pero la 
ingeniería de sala limpia diverge de las prácticas de 
software convencionales al quitar importancia (hay 
quien diría eliminar) al papel de las pruebas de unidad 
y ala depuración y al reducir dramáticamente (o elimi- 
nar) la cantidad de comprobaciones que son realizadas 
por quien desarrolla el software". 

En el desarrollo convencional del software, los erro- 
res se aceptan como cosas que pasan. Dado que se con- 
sidera que los errores son inevitables, cada módulo del 
programa debe ser comprobadounitariamente (para des- 


26.2 ESPECIFICACIÓN FUNCIONAL 


Independientementedel método de análisis selecciona- 
do, los principios de operación presentados en el Capí- 
tulo 11 siempre serán aplicables. Se modelan los datos, 
las funciones y el comportamiento. Los modelos resul- 
tantes deben de ser descompuestos (refinados) para pro- 
porcionar un grado de detalle cada vez más elevado. El 
objetivo global consiste en pasar de una especificación 
que captura la esencia de un problema, a una especifi- 
cación que proporciona una cantidad de detalle sustan- 
cial para su implementación. 

La ingeniería del software de sala limpia satisface 
los principios de análisis operacional por cuanto emplea 
un método denominado especificación de estructuru de 
caja. Una «caja» encapsula el sistema (o algún aspec- 
to del sistema) con un cierto grado de detalle. Median- 
te un proceso de refinamiento progresivo, se van 
refinando las cajas para formar una jerarquía en la cual 
cada caja tiene transparencia referencial. Esto es, «el 
contenido de información de cada especificación de caja 
basta para definir su refinamiento, sin depender de la 
implementación de ninguna otra caja» [LIN94]. Esto 
capacita al analista para desglosar jerárquicamente el 
sistema, pasando de la representación esencial situada 
en la parte superior, hasta los detalles específicos de la 
implementación situados en la parte inferior. Se utili- 
zan tres tipos de cajas: 


ULas pruebas se realizan, pero las efectúa un equipo independiente 
de pruebas 
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cubrir los errores) y depurado después (para eliminar 
los errores). Cuando se publica finalmente el software, 
la utilización práctica descubre aun más defectos, y 
comienza otro ciclo de comprobación y depuración. Este 
trabajo repetido asociado a las actividades menciona- 
das resulta costoso y lleva mucho tiempo. Y lo que es 
peor, puede ser degenerativo; la corrección de errores 
puede (inadvertidamente) dar lugar a la introducción de 
otros errores. 


En la ingeniería del software de sala limpia, la com- 
probación unitaria y la depuración se ven sustituidas 
por una verificación de corrección y por pruebas basa- 
das en la estadística.Estas actividades,junto con el man- 
tenimiento de registros para una continua mejora, hacen 
que el enfoque de sala limpia sea único. 


Caja negra. Esta caja especifica el comportamien- 
to del sistema, o de parte de un sistema. El sistema (o 
parte de él) responde a estímulos específicos (sucesos) 
mediante la aplicación de un conjunto de reglas de 
transición que hacen corresponder el estímulo con la 
respuesta. 


Caja de estado. Esta caja encapsula los datos de 
estados y de servicios (operaciones) de forma análo- 
ga a los objetos. En esta vista de especificación, se 
representan las entradas de la caja de estados (los estí- 
mulos) y sus salidas (las respuestas). La caja de esta- 
dos también representa la «historia de estímulos» de 
la caja negra, es decir, los datos encapsulados en la 
caja de estado que deben ser mantenidos entre las tran- 
siciones implicadas 


Caja limpia. Las funciones de transición que están 
implicadas en la caja de estado se definen en la caja 
limpia. Dicho literalmente, la caja limpia contiene el 
diseño procedimental correspondiente a la caja de esta- 
dos. 


¿ Cómo se lleva o cabo 

el refinamiento como parte 
de lo especificación de estructura 
de caja negra? 
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La Figura 26.2 ilustra el enfoque de refinamiento 
mediante el uso de una especificación de estructura de 
cajas. Una caja negra (CN,) define las respuestas de 
todo un conjunto completo de estímulos. CN, se pue- 
de refinar en un conjunto de cajas negras, desde UN, , 
hasta CN,,,,cadauna de las cuales aborda una cierta 
clase de comportamiento. El refinamiento prosigue 
hasta que se identifique una clase cohesiva de com- 
portamiento (por ejemplo, CN, ,,). A continuación, se 
define una caja de estado (CE, ,,) para la caja negra 
(CN, , )- En este caso, CE, , contiene todos los datos 
y servicios necesarios para implementar el comporta- 
miento definido por CN,!,. Por último, se refina 
CE, y y para formar un conjunto de cajas transparen- 
tes (CT,, ,,) y se especifican los detalles de diseño de 
procedimientos. 

A medida que se va realizando cada uno de estos 
pasos de refinamiento, se produce también una verifi- 
cación de la corrección. Se verifican las especifica- 
ciones de las cajas de estado para asegurar que todas 
y cada una de ellas se ajustan al comportamiento defi- 
nido por la especificación de la caja negra predeceso- 
ra. De manera similar, se verifican las especificaciones 
de las cajas transparentes con respecto a la caja de esta- 
dos predecesora. 


o 
CLAVE 


El refinamiento de la estructura de cojas y la verificación 
de corrección ocurren simultáneamente. 


Es preciso tener en cuenta que los métodos de espe- 
cificación basados en métodos formales (Capítulo 25) 
se pueden utilizar en lugar del enfoque de especifica- 
ción de estructura de cajas. El unico requisito es que se 
puede verificar formalmente cada uno de los niveles de 
especificación. 


CN 


FIGURA 26.2.Refinamiento de la estructura de cajas. 
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26.2.1. Especificación de caja negra 


Una especificación de caja negra describe una abstrac- 
ción, estímulos y respuestas empleando la notación que 
se muestra en la Figura 26.3. [MIL88]. La función f' se 
aplica a una secuencia, $*, de entradas (estímulos) y 
esta función los transforma en una salida (respuesta), 
R, Para componentes sencillos de software, f, puede ser 
una función matemática, pero en general, f se describe 
empleando el lenguaje natural (o bien un lenguaje de 
especificación formal). 

Muchos de los conceptos introducidos para sistemas 
orientados a objetos son aplicables también para la caja 
negra. Las abstracciones de datos y las operaciones que 
manipulan estas abstracciones, se ven encapsuladas por 
la caja negra. Al igual que una jerarquía de clases, la 
especificación de caja negra puede mostrar las jerar- 
quías de utilización en que las cajas de nivel inferior 
heredan las propiedades de las cajas de nivel superior 
dentro de la estructura de árbol. 


Referencia cruzada 


los conceptos orientados o objetos se describen 
enel Copituio 20, 


26.2.2. Especificación de caja de estado 


La caja de estado es «una generalización sencilla de una 
máquina de estado»|MIL88]. Recordando la descripción 
del modelado de comportamiento y de los diagramas de 
transición de estados que se ofrece en el Capítulo 12, un 
estado es algún modo observable de comportamiento del 
sistema. AÁ medida que se produce el procesamiento, el 
sistema va respondiendo a sucesos (estímulos) efectuan- 
do una transición que parte del estado y llega a algún nue- 
vo estado. A medida que se efectúa la transición, puede 
producirse una acción. La caja de estado utiliza una abs- 
tracción de datos para determinar la transición al estado 
siguiente (respuesta) que se producirá como consecuen- 
cia de la transición. 


Caja negra, y 


FIGURA 26.4.Una especificación de caja de estado [MIL88]. 
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Según se muestra en la Figura 26.4, la caja de estado 
contiene una caja negra. El estímulo, S, que se introduce 
en la caja negra, procede de alguna fuente externa y de un 
conjunto de estados internos del sistema, 7. Mills pro- 
porciona una descripción matemática de la función, f, de 
la caja negra contenida en el seno de la caja de estado: 


gl SExTE>RXT 
donde g es una subfunción que está asociada a un esta- 
do específico f. Cuando se consideran en su conjunto, 


las parejas de estados y subfunciones (í, 2) definen la 
función de caja negra f. 


26.2.3. Especificación de caja limpia 


La especificación de caja limpia está íntimamente rela- 
cionada con el diseño de procedimientos y con la pro- 
gramación estructurada. En esencia, la subfunción 2, 
que se encuentra dentro de la caja de estado, se ve sus- 


tituida por las estructuras de programación estructura- 
da que implementa g. 


El diseño de procedimientos y la programación 
estuciurada se desciben en el Capítulo 16. 


Como ejemplo, considérese la caja limpia que se 
muestra en la Figura 26.5. La caja negra g, que se mues- 
tra en Figura 26.4 se ve sustituida por una sucesión de 
estructuras que contienen una estructura condicional. 
Éstas, a su vez, se pueden refinar para formar Cajas trans- 
parentes del interior a medida que vaya avanzando el 
procedimiento de refinamiento progresivo. 

Es importante tener en cuenta que la especificación 
de procedimientos descrita en lajerarquía de caja lim- 
pia se puede demostrar a efectos de corrección. Este 
tema se considerará en la sección siguiente. 


26.3 REFINAMIENTO Y VERIFICACIÓN DEL DISEÑO 


El enfoque de diseño que se utiliza en la ingeniería del 
software de sala limpia hace mucho uso de la filosofía 
de la programación estructurada. Pero, en este caso, la 
programación estructurada se aplica de forma mucho 
más rigurosa. 


Estado 


FIGURA 26.5. Una especificación de caja transparente. 


La funciones básicas de procesamiento (que se des- 
cribían durante los refinamientos anteriores de la espe- 
cificación) se refinan ahora utilizando una «expansión 
progresiva de funciones matemáticas en estructuras de 
conectividad lógica [por ejemplo, si-entonces-sino] y 
subfunciones, donde la expansión [se] efectúa hasta que 
todas las funciones identificadas pudieran ser enuncia- 
das directamente en el lenguaje de programación utili- 
zado para la implementación» [DYE92]. 

El enfoque de la programación estructurada se pue- 
de utilizar de forma eficiente para refinar la función, 
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pero ¿qué pasa con el diseño de datos'? En este aspec- 
to, entra en juego un cierto número de conceptos fun- 
damentales de diseño (Capítulo 13). Los datos del 
programa se encapsulan como un conjunto de abstrac- 
ciones a las cuales prestan servicio las subfuncionec. 
Los conceptos de encapsulamiento de datos, oculta- 
miento de información y los tipos de datos se utilizan 
entonces para crear el diseño de datos. 


Referencia Web 


El programa Do) STARTS ha desarrollado varias guías 
y cdooumentos de sala limpio: ftp.cdrom.com/ 
pub /ada/docs /cleanrm 


26.3.1. Refinamiento y verificación del diseño 


Cada especificación de caja limpia representa el diseño 
de un procedimiento (subfunción) necesario para efec- 
tuar una transición de caja de estado. Mediante la caja 
limpia, se utilizan las estructuras de programación 
estructurada y de refinamiento progresivo según se ilus- 
tra en la Figura 26.6. Una función de programa, f, se 
refina para dar lugar a una sucesión de subfunciones £ 
y h. Éstas a su vez se refinan para formar estructuras 
condicionales (si-entonces-sino y hacer-mientras).Un 
refinamiento posterior ilustra la elaboración lógica con- 
tinuada. 


¿ Qué condiciones 

se aplican para probar 
que las construcciones 
estructuradas son correctas? 
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FIGURA 26.6.Refinamiento progresivo. 


En cada nivel de refinamiento, el equipo de sala lim- 
pia” lleva a cabo una verificación formal de corrección. 
Para lograr esto, se asocia un conjunto de condiciones 
de corrección genéricas a las estructuras de programa- 
ción estructurada. Si se expande una función f para dar 
una sucesión £ y h, entonces la condición de corrección 
para todas las entradas de fes: 


» ¿Es cierto que g seguido por A da lugar a f? 
Si se refina una función p para llegar a una estruc- 
tura condicional (si-entonces-sino),la condición de 
corrección para toda entrada de p es: 


* ¿Siempre que sea cierta la condición (c) es cierto 
que y realizap y siempre que (c) sea falsa, es 
cierto que y realizap? 

Si se refina una función m en forma de bucle, las 
condiciones de corrección para todas las entradas 
de ni son: 


» ¿Está garantizada la finalización? 

» ¿Siempre que (c) sea verdadera es cierto que 71 
seguido por m realiza m, siempre que (c) sea 
falso, sigue realizándose m si se obvia el bucle? 


Ronso fp 


Si nos limitamos o construcciones estructurados cuando 
se creo un diseño de procedimientos, lo pruebo 

de lo corrección es sencillo. Si se violan los construcciones, 
los pruebas de corrección son difíciles o imposibles. 


2 Dado que todo el equipo está implicado en el proceso de verifica- 
ción, es menos probable que se produzca un error al efectuar la veri- 
ficación en sí. 


abs 
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Cada vez que se refina una caja limpia hasta el 
siguiente nivel de detalle, se aplican las condiciones de 
corrección indicadas anteriormente. 

Es importante tener en cuenta que la utilización de 
estructuras de programación estructurada restringe el 
número de comprobaciones de corrección que es pre- 
ciso efectuar. Se verifica una sola condición en busca 
de sucesiones; se verifican dos condiciones para los si- 
entonces-sino; y se verifican tres condiciones para los 
bucles. 

Con objeto de ilustrar alguna verificación de correc- 
ción para un diseño de procedimientos, se utiliza un sen- 
cillo ejemplo presentado por primera vez por parte de 
Linger y sus colaboradores [LYN79]. Nuestro objetivo 
es diseñar y verificar un pequeño programa que calcu- 
le la parte entera, y, de una raíz cuadrada de un entero 
dado, x. El diseño de procedimientos se representa 
empleando el diagrama de flujo de la Figura 26.7. 


Raíz cuadrada | 


FIGURA 26.7. Cálculo de la parte entera de una raíz 
cuadrada [LIN79]. 


Para verificar la corrección de este diseño, es preci- 
so definir las condiciones de entrada y de salida que se 
indican en la Figura 26.8. La condición de entrada indi- 
ca que x debe ser mayor o igual a O. La condición de 
salida requiere que x permanezca intacta y que adopte 
un valor dentro del intervalo mostrado en la figura. Para 
demostrar que el diseño es correcto, es necesario demos- 
trar que las condiciones comienzo, bucle, cont, si y sali- 
da mostradas en la Figura 26. 8 son ciertas en todos los 
casos. En algunas ocasiones se denominan subdemos- 
traciones, 
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Raíz 


cuadrada | Entrada: [x > 0] 


y salida: x intacto, e y2< x < (y+ 1)2 


FIGURA 26.8.Demostración de la corrección del diseño 
[LIN79]. 


1. La condición comienzo exige que [x 20 e y =0)1. 
Basándose en los requisitos del problema, se supone 
que la condición de entrada es correcta'. Consi- 
gulentemente, se satisface la primera parte de la con- 
dición comienzo, x 2 0. En el diagrama de flujo, la 
sentencia que precede inmediatamente a la condi- 
ción comienzo hace que y =0. Consiguientemente, 
la segunda parte de la condición comienzo también 
se satisface. De aquí que comienzo sea verdadero. 


2. La condición bucle se puede encontrar de dos mane- 
ras: (1) directamente saliendo de comienzo (en este 
caso, la condición del bucle se satisface directamente) 
o bien (2) a través del control de flujo que pasa por 
la condición cont. Dado que la condición cont es 
idéntica a la condición bucle, bucle es verdadera inde- 
pendientemente de la rama de flujo que lleve a ella. 


Poro demostrar la corrección de un diseño, primero 
se deben identificar todos los condiciones y demostrar 
que todo uno de ellos tomo un valor Booleono. 

Esto es lo que se lloma subdemostroción. 


3. Se llega a la condición conf únicamente después de 
haber incrementado en 1 el valor de y. Además, la 
ruta de flujo de control que lleva a cont solamente se 
puede invocar si la condición sí también es verda- 
dera. Consiguientemente si (y + 1)?<x, se sigue que 
y? < x. La condición conf se satisface. 


4. La condición si se comprueba en la lógica condicio- 
nal que se muestra. Consiguientemente, la condición 
si debe de ser verdadera cuando el flujo de control 
pase por la vía mostrada. 

5. La condición salido exige, en primer lugar, que x no 
haya cambiado. Un examen del diseño indica que x 
no aparece en ningún lugar a la izquierda de un ope- 
rador de asignación. No hay ninguna llamada a fun- 


* Un valor negativo para una raia cuadrada carece de significado en 
este contexto. 


ción que utilice x. Por tanto, queda intacto. Dado que 
la comprobación de condiciones (y + 1)? < x tiene 
que fallar para alcanzar la condición solido, se sigue 
que (y + 1)? <x. Además, la condición bucle debe 
seguir siendo verdadera (esto es, F < x). Consi- 
guientemente, que (y + D?>xe y“ <x se pueden 
combinar para satisfacer la condición de salida. 

Además, es preciso asegurar que finalice el bucle. 
Un examen de la condición del bucle indica que dado 
que y se va incrementando y que x 2 O, el bucle final- 
mente debe terminar. 

Los cinco pasos indicados anteriormente son una 
demostración de la corrección del diseño del algoritmo 
indicado en la Figura 26.7. Ahora estamos seguros de 
que el diseño calculará, realmente, la parte entera de 
una raíz cuadrada. 

Es posible utilizar un enfoque matemáticamente más 
riguroso de la Verificación del diseño. Sin embargo, un 
debate sobre este tema iría más allá del alcance de este 
libro. Los lectores interesados pueden consultar [LIN79]. 


26.3.2. Ventajas de la verificación del diseño* 


La verificación de corrección rigurosa de cada uno de 

los refinamientos del diseño de caja limpia posee un 

cierto número de ventajas evidentes. Linger [LIN94] 
las describe de la siguiente manera: 

. Sereduce la verificación a un proceso finito. La 
forma anidada y secuencial, en que se organizan las 
estructuras de control en una caja limpia, define de 
manera natural una .jerarquía que revela las condi- 
ciones de corrección que es preciso verificar. Un 
axioma de sustitución [LIN79] nos permite reem- 
plazar las funciones objetivo por sus refinamientos 
de estructura de control dentro de lajerarquía de sub- 
demostraciones. Por ejemplo, la subdemostracióii 
para la función final f1 de la Figura 26.9 requiere que 
la comprobación de las operaciones gl y g2 con la 
función final f2 produzca sobre los datos el mismo 
efecto fl. Obsérvese que f2 reemplaza a todos los 
detalles de su refinamiento dentro de la demostra- 
ción. Esta sustitución localiza el argumento de 
demostración en la estructura de control que se está 
estudiando. De hecho, permite al ingeniero del soft- 
ware realizar demostraciones en cualquier orden. 


 ¿ Qué es lo que se gana 
- realizando las demostraciones 
de corrección? 


+. Es imposible asociar una importancia excesiva al 
efecto positivo que posee sobre la calidad lo reduc- 
ción de la verificación a un proceso finito. Aun 
cuando todos, salvo los programas más triviales, 
muestran un conjunto, que en esencia es infinito, de 


4 Esta seccion y las Figuras 26 7 hasta la 26 9 se han adaptado de 
[LIN94] Se utilizan con permiso del autor 


www.elsolucionario.net 


rutas de ejecución, se pueden verificar en un número 
finito de pasos. 


e 

o 

CLAVE 
Aun cuando en un proyromo hay uno contidod 
extremodomente grande de formas de ejecución, 


los posos poro demostrar que un proyromo 
es correcto son muy pocos. 


f1=[DO 91; 92; [f2] ENDI? 


f2 = [WHILE p1 DO[f3] ENDI ? 


f3 = [DO 93; [f4]; g8 ENDI ? 
14 [IF p2; THEN 1f5] ELSE [16] ENDI ? 


2 
THEN [f5] f5 = [DO 94; gb ENDI ? 
g4 


go 
ELSE [f6] f6 =[DO g6; g7 ENDI ? 


FIGURA 26.9.Diseño con subdemostraciones [LIN94]. 


» Permite que los equipos de sala limpia verifiquen 
todas las líneas de diseño y de código. Los diseños 
pueden efectuar la verificación mediante un análisis 
y debate en grupo de las bases del teorema de correc- 
ción y pueden producir pruebas escritas cuando se 
necesite una confianza adicional en algún sistema 
crítico para vidas o misiones. 


» Da lugar a un nivel de defectos próximo a cero. 
Durante una revisión en equipo, se verifica por tur- 
nos la corrección de todas y cada una de las estruc- 
turas de control. Cada miembro del equipo debe estar 


26.4 PRUEBA DE SALA LIMPIA 


La táctica y estrategia de la prueba de sala limpia es algo 
fundamentalmente distinto de los enfoques convencio- 
nales de comprobación. Los métodos convencionales 
derivan de casos de prueba para descubrir errores de 
diseño y de codificación. El objetivo de los casos de 
prueba de sala limpia es validar los requisitos del soft- 
ware mediante la demostración de que una muestra esta- 
dística de casos prácticos (Capítulo 11) se han ejecutado 
con éxito. 


26.4.1. Prueba estadística de casos prácticos 


El usuario de un programa de computadora no suele 
necesitar comprender los detalles técnicos del diseño. 
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de acuerdo en que cada condición es correcta, por 
tanto, un error solamente es posible si todos y cada 
uno de los miembros del equipo verifican incorrec- 
tamente una condición. El requisito de acuerdo uná- 
nime basada en las verificaciones individuales de 
resultados da lugar a un software que posee pocos o 
ningún defecto antes de su primera ejecución. 


Es escalable, Todo sistema de software, indepen- 
dientemente de su tamaño, posee unos procedi- 
mientos de caja transparente del más alto nivel 
formados por estructuras de secuencia, alternancias 
e iteraciones. Cada uno de estos invoca típicamente 
a un gran subsistema que posee miles de líneas de 
código — cada uno de estos subsistemas posee su 
propio nivel superior de funciones y procedimientos 
finales —. Por tanto, las condiciones de corrección 
para estas estructuras de control de alto nivel se veri- 
fican de la misma forma en que se procede con las 
estructuras de bajo nivel. Las verificaciones de alto 
nivel pueden requerir, y merecerá la pena, una mayor 
cantidad de tiempo, pero no se necesita más teoría. 


* Produce uncódigo mejor que la comprobación uni- 
taria. La comprobación unitaria solamente com- 
prueba los efectos de ejecutar vías de pruebas 
seleccionadas entre muchas vías posibles. Al basar 
la verificación en la teoría de funciones, el enfoque 
de sala limpia puede verificar todos y cada uno de 
los posibles efectos sobre los datos, porque aun 
cuando un programa pueda tener múltiples vías de 
ejecución, solamente posee una función. La verifi- 
cación es, además, más eficiente que la comproba- 
ción unitaria. La mayor de las condiciones de 
verificación se pueden verificar en unos pocos minu- 
tos, pero las comprobaciones unitarias requieren una 
cantidad notable de tiempo para prepararlas, ejecu- 
tarlas y comprobarlas. 


Es importante tener en cuenta que la verificación de 
diseño debe de aplicarse en última instancia al código 
fuente en sí. En este contexto, suele denominarse ver- 
ficación de corrección. 


El comportamiento visible para el usuario de ese pro- 
grama está controlado por las entradas y sucesos que 
suelen ser producidos por el usuario. Pero en casos com- 
plejos, el espectro posible de entradas y sucesos (esto 
es, los casos prácticos) pueden ser extremadamente 
variables. ¿Cuál es el subconjunto de casos prácticos 
que verifica adecuadamente el comportamiento del pro- 
grama? Ésta es la primera cuestión que aborda la prue- 
ba estadística de casos prácticos. 

La prueba estadística de casos «equivale a probar 
el software en la forma en que los usuarios tienen 
intención de utilizarlo» |[LIN94]. Para lograr esto, los 
equipos de prueba de sala limpia (también llamados 
equipos de certificación) deben determinar la distri- 
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bución de probabilidad de utilización correspondien- 
te al software. La especificación (caja negra) de cada 
incremento del software se analiza para definir un con- 
junto de estímulos (entradas o sucesos) que pueden 
dar lugar a que el software modifique su comporta- 
miento. Basándose en entrevistas con posibles usua- 
rios, en la creación de escenarios de utilización y en 
una comprensión general del dominio de la aplica- 
ción, se asigna una probabilidad de utilización a cada 
uno de los estímulos. 

Los casos prácticos se generan para cada uno de los 
estímulos' de acuerdo con la distribución de probabili- 
dad de utilización. Como ejemplo, considérese el siste- 
ma de seguridad HogarSeguro descrito anteriormente 
en este libro. Se está utilizando la ingeniería del soft- 
ware de sala limpia para desarrollar un incremento del 
software que gestione la interacción del usuario con el 
teclado del sistema de seguridad. Para este incremento 
se pueden identificar cinco estímulos. El análisis indi- 
cael porcentaje de probabilidad de cada estímulo. Para 
hacer que sea más sencilla la selección de casos de prue- 
ba, estas probabilidades se hacen corresponder con inter- 
valos numerados entre 1 y 99 [LIN94], lo que se muestra 
en la tabla siguiente: 


Estímulos Probabilidad Intervalo 
del programa 

habilitar/ 

deshabilitar (HD) 50% 1-49 
fijar zona (EZ) 15% 50-63 
consulta (C>) 15% 64-78 
prueba (P) 15% 79-94 
alarma (A) 5% 95-99 


Para generar una sucesión de casos de prueba de 
utilización que se ajuste a la distribución de probabi- 
lidades de utilización, se genera una serie de núme- 
ros aleatorios entre 1 y 99. El número aleatorio 
corresponde al intervalo de distribución de probabi- 
lidad anteriormente destacado. Consiguientemente, la 
sucesión de casos prácticos se define aleatoriamente 
pero se corresponde con la probabilidad correspon- 
diente de aparición de ese estímulo. Por ejemplo, 
suponga que se generan las siguientes sucesiones de 
números aleatorios 


13-94-22-24-45-56 
81-19-31-69-45-9 
38-21-52-84-86-4 
Se derivan los siguientes casos prácticos median- 
te la selección de los estímulos adecuados basados en 


5 Se utilizan herramientas automatizadas con este fin Para mas infor 
macion, vease [DYE92] 
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el intervalo de distribución que se muestra en la tabla 
anterior: 


HD-P-HD-HD-HD-—FZ 
P-HD-HD-HD-C-HD-H D 
HD-HD-FZ—P-P-HD 


El equipo de prueba ejecuta los casos prácticos indi- 
cados anteriormente (y otros más) y verifica el compor- 
tamiento del software frente a la especificación del 
sistema. La temporización de las pruebas se registra, de 
modo que sea posible determinar los intervalos tempo- 
rales. Mediante el uso de intervalos temporales, el equi- 
po de certificación puede calcular el tiempo-mínimo-entre 
fallos. Si se lleva a cabo una larga sucesión de pruebas 
sin fallo, el TMEF es bajo, y se puede suponer que la fia- 
bilidad del software es elevada. 


26.4.2. Certificación 


Las técnicas de verificación y prueba descritas ante- 
riormente en este capítulo dan lugar a componente5 
de software (y a incrementos completos) que se pue- 
den certificar. En el contexto del enfoque de la inge- 
niería del software de sala limpia, la certificación 
implica que la fiabilidad (medida por el tiempo míni- 
mo de fallo, TMDE) podrá ser especificada para cada 
componente. 

El posible impacto de los componentes de software 
certificables va más allá de un sencillo proyecto de sala 
limpia. Los componentes de software reutilizables se 
pueden almacenar junto con sus escenarios de utiliza- 
ción, con los estímulol del programa y con las corres- 
pondientes distribuciones de probabilidad. Cada uno de 
los componentes dispondrá de una fiabilidad certifica- 
da dentro del escenario de utilización y dentro del régi- 
men de comprobación descrito, Esta información es 
sumamente valiosa para otras personas que tengan inten- 
ción de utilizar estos componentes. 

El enfoque de la certificación implica cinco pasos 
[WOHD9A4]: 

[. Es preciso crear escenarios de utilización. 

2. Se especifica un perfil de utilización. 

3. Se generan casos de prueba a partir del perfil. 


4. Se ejecutan pruebas y los datos de los fallos se 
registran y se analizan. 


5. Se calcula y se certifica la fiabilidad. 


¿ Cómo se certifica un 
componente de software? 


Los pasos l a 4 se han descrito en secciones ante- 
riores. En esta sección, nos concentramos en la certifi- 
cación de fiabilidad. 
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La certificación para la ingeniería del software de sala 
limpia requiere la creación de tres modelos [P0034]: 

Modelo de muestreo. La comprobación de softwa- 
re ejecuta mm casos de prueba aleatorios, y queda certi- 
ficada si no se produce ningún fallo o si se produce un 
número de fallos inferior al especificado. El valor de m 
se deriva matemáticamente para asegurar que se alcan- 
ce la fiabilidad necesaria. 

Modelo de componentes. Es preciso certificar un sis- 
tema compuesto por n componentes. El modelo de com- 
ponentes capacita al analista para determinar la probabilidad 
de que falle el componente i antes de finalizar el programa. 


RESUMEN 


La ingeniería del software de sala limpia es un enfoque 
formal para el desarrollo del software, que puede dar 
lugar a un software que posea una calidad notablemen- 
te alta. Emplea la especificación de estructura de cajas 
(o métodos formales) para el modelado de análisis y 
diseño, y hace hincapié en la verificación de la correc- 
ción, más que en las pruebas, como mecanismo funda- 
mental para hallar y eliminar errores. Se aplica una 
prueba estadística de utilización para desarrollar la infor- 
mación de tasa de fallos necesaria para certificar la fia- 
bilidad del software proporcionado. 

El enfoque de sala limpia comienza por unos modelos 
de análisis y diseño que hacen uso de una representación 
de estructurade cajas. Una «caja» encapsula el sistema (o 
algún aspecto del sistema) en un determinado nivel de 
abstracción. Se utilizan cajas negras para representar el 
comportamiento observable externamente de ese sistema. 
Las cajas de estado encapsulan los datos y operaciones de 
ese estado. Se utiliza una caja limpia para modelar el dise- 
ño de procedimientos que está implicado por los datos y 
operaciones de la caja de estados. 

Se aplica la verificación de corrección una vez que 
está completo el diseño de estructura de cajas. El dise- 
ño de procedimientos para un componente de software 
se desglosará en una serie de subfunciones. Para demos- 
trar la corrección de cada una de estas subfunciones, se 
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Modelo de Certificación.Se estima y certifica la fia- 
bilidad global del sistema. 

Al final de la prueba estadística de utilización, el 
equipo de certificación posee la información necesaria 
para proporcionar un software que tenga un TMEF cer- 
tificado que se habrá calculado empleando todos estos 
modelos. 

Una descripción detallada del cálculo de los mode- 
los de muestreo, de componentes y de certificación va 
más allá del alcance de este libro. El lector interesado 
encontrará detalles adicionales en [MUS87], [CUR806] 
y [PO0931. 


definen condiciones de salida para cada una de las sub- 
funciones y se aplica un conjunto de subpruebas. Si se 
satisfacen todas y cada una de las condiciones de sali- 
da, entonces el diseño debe ser correcto. 

Una vez finalizada la verificación de corrección, 
comienza la prueba estadística de utilización. A dife- 
rencia de la comprobación condicional, la ingeniería del 
software de sala limpia no hace hincapié en la prueba 
unitaria o de integración. En su lugar, el software se 
comprueba mediante la definición de un conjunto de 
escenarios, mediante la determinación de las probabi- 
lidades de utilización de cada uno de esos escenarios y 
mediante la aplicación posterior de pruebas aleatorias 
que satisfagan estas probabilidades. Los registros de 
error resultantes se combinan con modelos de muestreo, 
de componentes y de certificación para hacer posible el 
cálculo matemático de la fiabilidad estimada de ese com- 
ponente de software. 

La filosofía de sala limpia es un enfoque riguroso de 
la ingeniería del software. Se trata de un modelo de pro- 
ceso del software que hace hincapié en la verificación 
matemática de la corrección y en la certificación de la 
fiabilidad del software. El resultado final son unas tasas 
de fallo extremadamente bajas, que sería difícil o impo- 
sible de conseguir empleando unos métodos menos for- 
males. 
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PROBLEMAS Y PUNTOS A CONSIDERAR 


26.1. Si tuviera que seleccionar un aspecto de la ingeniería del 
software de sala limpia que la hiciera radicalmente distinta de 
los enfoques convencionales u orientados a objetos de la inge- 
niería del software, ¿cuál sería"? 


26.2. ¿Cómo se combinan el modelo de proceso incremental 
y el trabajo de certificación para construir un software de ele- 
vada calidad"! 


26.3. Empleando la estructura de especificaciónde cajas, desa- 
rrollar un análisis de «primer paso» y unos modelos de dise- 
ño para el sistema HogarSeguro. 


26.4. Desarrolle una especificación de estructura de cajas para 
una parte del sistema SSRB presentado en el Problema 12.13. 


26.5. Desarrolle una especificación de estructura de cajas para 
el sistema de correo electrónico en el Problema 21.14. 


26.6. Se define el algoritmo de ordenación por el método de 
las burbujas de la forma siguiente: 

procedure ordenburbuja; 

Vaz dy E y MtLeger; 

begin 
== 8] 7 
ESSE ¡00 
for j := 2 ton do 

ifalj-1] > alj] then begin 


t:=a[j-11; 
alj-1]:= a[j] 
alj] := t; 
ale" 
endrep 
enu' 


Descomponer el diseño en subfunciones y definir un conjun- 
to de condiciones que hagan posible demostrar que este algo- 
ritmo es correcto. 


26.7. Documentar una demostración de verificación de correc- 
ción para la ordenación por el método de la burbuja descrita 
en el Problema 26.6. 


26.8. Seleccionar un componente de programa que se haya 
diseñado en otro contexto (o bien asignado por el instruc- 
tor) y desarrollar para él una demostración completa de 
corrección. 


26.9. Seleccionar un programa que se utilice regularmente (por 
ejemplo, un gestor de correo electrónico, un procesador de 
texto, una hoja de cálculo). Crear un conjunto de escenarios 
de utilización para ese programa. Definir la probabilidad de 
utilización de cada escenario y desarrollar entonces una tabla 
de estímulos del programa y de distribución de probabilida- 
des parecida a la que se muestra en la Sección 26.4.1. 


26.10. Para la tabla de estímulos del programa y de distribu- 
ción de probabilidades desarrollada en el Problema 26.9, uti- 
lizar un generador de números aleatorios con objeto de 
desarrollar un conjunto de casos de prueba para utilizarlo en 
una prueba estadística de utilización. 


26.11. Con sus propias palabras, describa el objetivo de la cer- 
tificación en el contexto de la ingeniería del software de sala 
limpia. 


26.12. Escribir un pequeño'trabajo que describa las matemá- 
ticas utilizadas para definir los modelos de certificación des- 
critos brevemente en la Sección 26.4.2. Utilícense [MUS87], 
[CUR86] y [POP93] como punto de partida. 


Prowell et al. (Cleanroom Software Engineering: Techno- 
logy and Process, Addison-Wesley, 1999) describe con 
profundidad todos los aspectos importantes del enfoque de 
sala limpia. Estudios Útiles sobre los temas de sala limpia 
han sido editados por Poore y Trammell (Cleanroom Soft- 
ware: A Reader, Blackwell Publishing, 1996). Becker y 
Whittaker (Cleanroom Software Engineering Practices, 
Idea Group Publishing, 1996) presentan una visión general 
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excelente para aquellas personas que no estén familiarizadas 
con las prácticas de sala limpia. 

The Cleanroom Panphlet (Software Technology Support 
Center, Hill AF Base, UT, abril 1995) contiene reimpresiones 
de varios artículos importantes. Linger [LIN94] es una de las 
mejores introducciones a este tema. Asset Source for Softwa- 
re Engineering Technology, ASSET (Departamento de Defen- 
sa americano) ofrece un conjunto excelente de seis volúmenes 
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de Cleanroom Engineering Handbooks. Se puede contactar 
con ASSET en info Esource.asset.com. Lockheed Martin ha 
preparado la guía Guide to the Integration of Object-Orien- 
ted Methods and CleanroomSoftware Engineering (1997) que 
contiene un proceso genérico de sala limpia para sistemas ope- 
rativos y está disponible en: 

http://www. asset .com/stars/cleanroom/oo/guidhome . htm 


Linger y Trammell (Cleanroom Software Engineering 
Reference Model, SEI Technical Report CMU/SEI-96-TR- 
022, 1996) han definido un conjunto de 14 procesos de sala 
limpia y 20 productos de trabajos que forman la base del SEl 
CMM para la ingeniería del software de sala limpia 
(CMU/SEI-96-TR-023). 

Michael Deck, de Cleanroom Software Engineering, Ínc., 
ha preparado una bibliografía sobre temas de sala limpia. 
Entre las referencias se encuentran las siguientes: 


Generales e Introductorias 

Deck, M.D., «Cleanroom Software Engineering Myths 
and Realities», Quality Week 1997, San Francisco, CA, Mayo 
de 1997. 

Deck, M.D, y J.A. Whittaker, «Lessons Learned from Fif- 
teen Years of Cleanroom Testing», Software Testing, Analysis, 
and Review (STAR)'97,San José, CA, 5-9 de Mayo de 1997. 

Lokan, C.J., «The Cleanroom for Software Development», 
The Australian Computer Journal, vol. 25, n.2 4, Noviembre 
de 1993. 

Linger, Richard C., «Cleanroom Software Engineering for 
Zero-Defect Software», Proc. 15th International Conferen- 
ce Internationul on Software Engineering, Mayo de 1993. 

Keuffel, W., «Clean Your Room: Formal Methods for the 
90's», Computer Language, Julio de 1992, pp. 39-46. 

Hevner, A.R, S.A. Becker y L.B. Pedowitz, «Integrated 
CASE for Cleanroom Development», IEEE Software, Mar- 
zo de 1992, pp. 69-76. 

Cobb, R.H. y H.D. Mills, «Engineering Software under 
Statistical Quality Control», IEEE Software, Noviembre de 
1990, pp. 44-45. 


Practicas de Gestión 

Becker, S.A., M.D. Deck y T. Janzon, «Cleanroom and Orga- 
nizational Change», Proc. 14% Pacific Northwest Software Qua- 
lity Conference, Portland, OR, 29-30 de Octubre de 1996. 

Linger, R.C., «Cleanroom Process Model», IEEE Soft- 
ware, marzo de 1994, pp. 50-58. 

Linger, R.C. y Spangler, R.A., «The IBM Cleanroom Soft- 
ware Engineering Technology Transfer Program», Sixth SEI 
Conference on Software Engineering Education, San Diego, 
CA, Octubre de 1992. 


Especificación, Diseño y Revisión 

Deck, M.D., «Cleanroom and Object-Oriented Software 
Engineering:A Unique Synergy», I Y96 Software Technology 
Conference, Salt Lake City, UT, 24 de Abril de 1996. 
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Deck, M.D., «Using Box Structures to Link Cleanroom 
and Object-Oriented Software Engineering», Technical Report 
94.01h, Cleanroom Software Engineering Inc., Boulder, CO, 
1994, 

Dyer, M. «Designing Software for Provable Correctness: 
the direction for quality software», Information and Softwa- 
re Technology, vol. 30,n.* 6, Julio/Agosto de 1988, pp. 331- 
340. 


Pruebas y Certificación 

Dyer, M.,«An Approach to Software Reliability Measu- 
rement», Information and Software Technology, vol. 29, n,2 
8, Octubre de 1987, pp. 415-420. 

Head, G.E., «Six-Sigma Software Using Cleanroom Soft- 
ware Engineering Techniques», Hewlett-Packard Journal, 
Junio de 1994, pp. 40-50. 

Oshana, R., «Quality Software via a Cleanroom Metho- 
dology», Emhedded Systems Programming, Septiembre de 
1996, pp. 36-52. 

Whittaker, J.A., y Thomason, M.G., «A Markov Chain 
Model for Statistical Software Testing», JEEE Trans. on Soft- 
wure Engineering, Octubre de 1994, pp. 812-824. 


Estudios de casos e informes experimentales 

Head, G.E., «Six-Sigma Software Using Cleanrooin Soft- 
ware Engineering Techniques», Hewlett-Packard Journal, 
Junio de 1994, pp. 40-SO. 

Hevner, A.R., y H.D. Mills, «Box-structured methods for 
systems development with objects», IBM systems Journal, 
vol. 32,n.9 2, 1993, pp. 232-251, 

Tann, L-G., «0832 and Cleanroom», Proc. 1% Annual 
European Industrial Symposium on Cleanroom Software Engi- 
neering, Copenhagen, Denmark, 1993, pp. 1-40. 

Hausler, P.A., «A Recent Cleanroom Success Story: The 
Redwing Project», Proc. 17'% Annual Software Engineering 
Workshop, NASA Goddard Space Flight Center, Diciembre 
de 1992, 

Trammel, C.J., Binder L.H. y Snyder, C.E., «The Auto- 
mated Production Control Documentation System: A Case 
Study in Cleanroom Software Engineering», ACM Trans. on 
Software Engineering and Methodology, vol. 1, n.£ 1, Enero 
de 1992, pp. 81-94. 

La verificación de diseños mediante pruebas de correc- 
ción se encuentra en el centro del enfoque de sala limpia. En 
los libros de Baber (Error-Free Software, Wiley, 1991) y 
Schulmeyer (Zero Deject Software, McGraw-Hill, 1990) se 
estudia la prueba de corrección de forma muy detallada. 

En Internet se puede encontrar disponible mucha infor- 
mación variada sobre la ingeniería del software de sala lim- 
pia y sobre temas relacionados. Para conseguir una lista 
actualizada de referencias que sea relevante para la ingenie- 
ría del software de sala limpia se puede visitar http://www 
pressman5.com 
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CAPÍTULO 


27 


INGENIERÍA DEL SOFTWARE 
BASADA EN COMPONENTES 


N el contexto de la ingeniería del software, la reutilización se puede considerar una idea 
nueva y antigua. Los programadores han reutilizado ideas, abstracciones y procesos des- 
de el principio de la era de los computadores, pero el primer enfoque de reutilización era 
muy concreto. Hoy en día, los sistemas complejos y de alta calidad basados en computadora se 
deben construir en períodos de tiempo muy cortos. Esto se mitiga con un enfoque de reutiliza- 
ción más organizado. 
La ingeniería del software basada en componentes (ISBC) es un proceso que se centra en 
el diseño y construcción de sistemas basados en computadora que utilizan «componentes» de 
software reutilizables. Clements [CLE95] describe la ISBC de la manera siguiente: 


[La ISBC] está cambiando la forma en que se desarrollan los sistemas de software. [La ISBC] repre- 
senta la filosofía de «comprar, no construir», que expusieron Fred Brooks y otros. De la misma manera que 
las primeras subrutinas liberaban al programador de tener que pensar en detalles, [ISBC] cambia su objeti- 
vo y pasa de programar el software a componer sistemas de software. La implementación ha dado paso a 
la integración como núcleo del enfoque. Se puede decir que en su base se encuentra la suposición de que 
en muchos sistemas grandes de software existe una base común suficiente como para justificar los compo- 
nentes reutilizables para explotar y satisfacer a esa base común. 


Sin embargo, surgen muchas preguntas. ¿Es posible construir sistemas complejos ensamblán- 
dolos a partir de un catálogo de componentes de software reutilizables? ¿Se puede conseguir de una 
manera rentable y en poco tiempo? ¿Se pueden establecer incentivos para animar a que los inge- 
nieros del software reutilicen y no reinventen? ¿Están dispuestos los directivos a contraer los gastos 
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¿Qué es? Compre un equipo de música 


estéreo y lléveselo a casa. Cada com- 
ponente ha sido diseñado para aco- 
plarse en un estilo arquitectónico 
específico —las conexiones son están- 
dar y puede preestablecerse el protoco- 
lode comunicación —. El ensamblaje es 
fácil porque el sistema no tiene que 
construirse a partir de piezas por sepa- 
rado. La ingeniería del software basa- 
da en componentes (ISBC)lucha por 
conseguir lo mismo. Un conjuntode com- 
ponentes de software preconstruidos y 
estandarizados están disponibles para 
encajar en un estiloarquitectónicoespe- 
cífico pura algún dominiode aplicación. 
La aplicación seensambla entonces uti- 
lizando estos componentesy nolas .pie- 

zas por separado. de un lenguaje de 
programación convencional. 


¿Quién lo hace ? Los ingenieros del 


software. 


¿Por qué es importante? La instala- 


ción del equipo estéreo solo lleva unos 
pocos minutos, porque los componen- 
tes están diseñados para integrarse 
con facilidad. Aunque el software es 
considerablemente más complejo que 
el sistema estéreo, se puede seguir 


diciendo que los sistemas basados en 
componentes son más fáciles de 
ensamblar y, por tanto, más caros de 
construir a partirde piezas separadas. 
Además, la ISBC hace hincapié en la 
utilización de patrones arquitectónicos 
predecibles y en una infraestructura de 
software estándar, lo que lleva a un 
resultado de calidad superior. 


¡Cuáles son los pasos? La ISBC acom- 


paña a dos actividades de ingeniería 
paralelas: la ingeniería del dominio y 
el desarrollo basado en componentes. 
La ingeniería del dominio explora un 
dominio de aplicaciones con la inten- 
ción de encontrar específicamente los 
componentes de datos funcionales y de 
comportamiento candidatos para la 
reutilización. Estos componentes se 
encuentran en bibliotecas de reutiliza- 
ción. El desarrollo basado en compo- 
nentes obtiene los requisitos del cliente 
y selecciona el estilo arquitectónico 
adecuado para cumplir los objetivos 
del sistema que se va a construir, y a 
continuación: (1) selecciona posibles 
componentes para la reutilización; (2) 
cualifica los componentes para asegu- 
rarse de que encajan adecuadamente 
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en la arquitectura del sistema; (3)adap, 
ta los componentes si se deben hacer 
modificaciones para poderlos integrar 
adecuadamente; (4) integra los compo 
nentes para formar subsistemas y la 
aplicación completa. Además, loscom- 
ponentes personalizados se han dise- 
ñado para afrontar esos aspectos del 
sistema que no pueden implementarse 
utilizando componentes que ya existen. 


¿Cuál es el producto obtenido? El 


producto de la ISBCes el software ope- 
racional ensamblado utilizando los 
componentes de software existentes y 
los que se acaban de desarrollar. 


¿Cómo puedo estar seguro de que 


lo he hecho correctamente? Utili- 
zando las mismas prácticas SQA que 
se aplican en todos los procesos de 
ingeniería del software —las revisio- 
nes técnicas formales evalúan los 
modelos de análisis y diseño—-: las 
revisiones especializadas tienen en 
consideración temas asociados con los 
componentes adquiridos; y la compro- 
bación se aplica para descubrir errores 
enel software nuevo y en componentes 
reutilizables que se hayan integrado en 
la arquitectura. 
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añadidos y asociados con la creación de componentes de software reutilizables? ¿Se puede crear una biblioteca con los 
componentes necesarios para llevar a cabo la reutilización de manera accesible para aquellos que la necesitan? 

Estas y otras preguntas siguen vivos en la comunidad de investigadores y de profesionales de la industria que 
luchan por hacer que la reutilización de componentes de software sea el enfoque más convencional de la ingenie- 
ría del software. Algunas de estas preguntas se estudian en este capítulo. 


LE 3) 
Superficialmente, la ISBC parece bastante similar a la 
ingeniería del software orientada a objetos. El proceso 
comienza cuando un equipo de software establece los 
requisitos del sistema que se va a construirutilizando las 
técnicas convencionalesde obtención de requisitos (Capí- 
tulos 10y 11). Se establece un diseño arquitectónico 
(Capítulo 14), pero en lugar de entrar inmediatamente en 
tareas de diseño detalladas, el equipo examina los requi- 
sitos para determinar cuál es el subsistema que está dis- 
puesto para la composición, y no para la construcción. 
Esto es, el equipo formula las siguientes preguntas para 
todos y cada uno de los requisitos del sistema: 

¿Es posible disponer de componentes comerciales 
ya desarrollados (CY D) para implementar el requi- 
sito? 

¿Se dispone de componentes reutilizables desarro- 
llados internamente para implementar el requisito? 
¿Son compatibles las interfaces de los componentes 
que están disponibles dentro de la arquitectura del 
sistema a construir? 

El equipo intenta modificaro eliminar aquellos requi- 
sitos del sistema que no se pueden implementar con 
componentes CY D o de desarrollo propio". Silos requi- 
sitos no se pueden ni cambiar ni borrar, se aplican méto- 
dos de ingeniería del software convencionales u 
orientados a objetos para desarrollar los componentes 
nuevos que se deben diseñar para cumplir los requisi- 
tos. Pero para esos requisitos que se afrontan con los 
componentes disponibles comienza un conjunto dife- 
rente de actividades de ingeniería del software: 


Cualificación de componentes. Los requisitos del 
sistema y la arquitectura definen los componentes que 
se van a necesitar. Los componentes reutilizables (tan- 
to si son CY D como de desarrollo propio) se identifican 
normalmente mediante las características de sus inter- 
faces. Es decir, se describen «los servicios que se pro- 
porcionan y el medio por el que los consumidores 
acceden a estos servicios» [BRO96] como parte de la 
interfaz del componente. Pero la interfaz no proporcio- 
na una imagen completa del acople del componente en 
la arquitectura y en los requisitos. El ingeniero del soft- 
ware debe de utilizar un proceso de descubrimientoy de 
análisis para cualificar el ajuste de cada componente. 


' La implicación es que la organización ajusta sus requisitos comer- 
ciales o del producto de manera que se puede lograr la implementa- 
ción basada en componentes sin la necesidad de una ingeniería 
personalizada. Este enfoque reduce el coste del sistema y mejora el 
tiempo de comercialización, pero no siempre es posible. 
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¿Cuáles son las actividades 
del marco de trabajo 1SBC? 


Adaptación de componentes. En el Capítulo 14 se 
señaló que la arquitectura del software representa los 
patrones de diseño que están compuestos de componen- 
tes (unidades de funcionalidad), conexiones y coordina- 
ción. Esencialmentela arquitectura define las normas del 
diseño de todos los componentes, identificando los modos 
de conexión y coordinación. En algunos casos, es posi- 
ble que los componentes reutilizables actuales no se 
correspondan con las normas del diseño de la arquitec- 
tura. Estos componentes deben de adaptarse para cum- 
plir las necesidades de la arquitectura o descartarse y 
reemplazarse por otros componentes más adecuados. 


futuro-próximo la mayoría 
software se ensamblorán 
t no se construirán 


Composición de componentes. El estilo arquitec- 
tónico vuelve ajugar un papel clave en la forma en que 
los componentes del software se integran para formar 
un sistema de trabajo. Mediante la identificación de los 
mecanismos de conexión y coordinación (por ejemplo, 
las propiedades de ejecución en el diseño), la arquitec- 
tura dicta la composición del producto final. 


Actualización de componentes. Cuando se imple- 
mentan sistemas con componentes CYD, la actualiza- 
ción se complica por la imposición de una tercera parte 
(es decir, es posible que la empresa que desarrolló el 
componentereutilizable no tenga el control de la empre- 
sa de ingeniería del software). 

Todas y cada una de las actividades ISBC se estu- 
dian más profundamente en la Sección 27.4. 

En la primera parte de esta sección el término «com- 
ponente» se ha utilizando en repetidas ocasiones, a pesar 
de que es difícil de efectuar una descripción definitiva 
del término. Brown y Wallnau [BRO96] sugieren las 
siguientes posibilidades: 
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*  componente-— una parte reemplazable, casi indepen- 
diente y no trivial de un sistema que cumple una fun- 
ción clara en el contexto de una arquitectura bien 
definida; 

» componente del software en ejecución— un paquete 
dinámico de unión de uno O más programas gestio- 
nados como una unidad, alos que se accede a través 
de interfaces documentadas que se pueden descubrir 
en la ejecución; 

* componente de software- una unidad de composi- 
ción que solo depende del contexto contractual de 
forma específica y explícita; 

» componente de negocio-la implementación de soft- 
ware de un concepto comercial «autónomo» o de un 
proceso comercial; 

Además de las descripciones anteriores, los compo- 
nentes del software también se pueden caracterizar por el 
uso en el proceso ISBC. Además de los componentesCYD, 
el proceso ISBC produce los siguientes componentes: 

* componentes cualificados— evaluados por los inge- 
nieros de software para asegurar que no sólo la fun- 
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En el Capítulo 2, se utilizó un «modelo de desarrollo 
basado en componentes» (Fig. 2.12) para ilustrar la for- 
ma en que se integra una biblioteca de «componentes 
candidatos» reutilizables en un modelo típico de pro- 
ceso evolutivo. Sin embargo, el proceso ISBC se debe 
caracterizar de forma que no sólo identifique los com- 
ponentes candidatos sino que también cualifique la inter- 
faz de cada componente, que adapte los componentes 
para extraer las faltas de coincidencias arquitectónicas, 
que ensamble los componentes en un estilo arquitectó- 
nico seleccionado y que actualice los componentes a 
medida que cambian los requisitos del sistema [BRO96]. 


Ingeniería de dominio 
Análisis 

del 
dominio 


Desarrollo Desarollo 


Artefactos/ 
componentes 
reutilizables 
de la reserva 


Desarrollo basado 
en componentes 


Ingeniería de 
componentes 


FIGURA 27.1. Un modelo de proceso de soporte a la ISBC. 
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cionalidad sino también el rendimiento, la fiabilidad y 
otros factores de calidad (Capítulo19) encajan con los 
requisitos del sistema/producto que se va a construir; 


Referencia cruzada 


bo certificación de componentesse puede realizar 
con los métodos de salolimpio. Para obtener 
más información consultee Capítulo 26. 


- componentes adaptados- adaptados para modificar 
(también llamados «enmascarados»o «envoltorios») 
[BRO96] las características no deseadas. 

- componentes ensamblados- integrados en un estilo 
arquitectónico e interconectados con una infraes- 
tructura de componentes adecuada que permite coor- 
dinar y gestionar los componentes de forma eficaz; 

- componentes actualizados- el software actual se 
reemplaza a medida que se dispone de nuevas ver- 
siones de componentes; 

Dado que la ISBC es una disciplina en evolución, no 
es probable que en el futuro surja una definición unifi- 
cada. 


El modelo de proceso para la ingeniería del softwa- 
re basada en componentes hace hincapié en las pistas 
paralelas en las que aparece concurrentemente la inge- 
niería del dominio (Sección 27.3) con el desarrollo basa- 
do en componentes. La ingeniería del dominio realiza 
el trabajo que se requiere para establecer el conjunto de 
componentes de software que el ingeniero del softwa- 
re puede reutilizar. Estos componentes entonces se trans- 
fieren a través de un «límite» que separa la ingeniería 
del dominio del desarrollo basado en componentes. 


Referencia Web 


La página de tecnología de componentes proporciono 
información útil sobre ISBC: 
www.odateam.com/cop/ 


La Figura 27.1 ilustra un modelo de proceso típico que 
acopla la ISBC explícitamente [ CHR95]. La ingenieríadel 
dominio crea un modelo de dominio de aplicación que se 
utiliza como base para analizar los requisitos del usuario 
en el flujo de la ingeniería del software. Una arquitectura 
de software genérica (y los puntos de estructura corres- 
pondientes, véase la Sección 27.3.3) proporciona la entra- 
da para el diseño de la aplicación. Finalmente, después de 
que se han comprado los componentes reutilizables, se han 
seleccionado a partir de las bibliotecas existentes o se han 
construido (como parte de la ingeniería del dominio), los 
ingenieros del software dispondrán de ellos durante la acti- 
vidad de desarrollo basada en componentes. 
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El objetivo de la ingeniería del dominio es identificar, 
construir, catalogar y diseminar un conjunto de compo- 
nentes de software que tienen aplicación en el software 
actual y futuro dentro de un dominio de aplicación en 
particular. El objetivo general consiste en establecermeca- 
nismos que capaciten a los ingenieros del software para 
compartir estos componentes —para reutilizarlos —a lo 
largo de su trabajo en sistemas nuevos o actuales. 


está a punto de encontrar 
: pora identificar 

é pueden aplicar a muchos 

car los fomilias 

están ubicados de forma 

cho de esos componentes. 


La ingeniería del dominio incluye tres actividades 
principales: análisis, construcción y diseminación. En 
el Capítulo 2 1 se presentó una revisión general del aná- 
lisis del dominio. Sin embargo, este tema se vuelve a 
tratar en las secciones siguientes. La construcción y la 
diseminación del dominio se describirán más adelante 
en otras secciones dentro de este mismo capítulo. 

Se podría argumentar que «la reutilización desapa- 
recerá, no mediante la eliminación, sino mediante la 
integración» en el entramado de prácticas de la inge- 
niería del software[TRA95]. Como la reutilización cada 
vez recibe más importancia, todavía hay quien cree que 
en la próxima década la ingeniería del dominio tendrá 
tanta importancia como la ingeniería del software. 


27.3.1. El proceso de análisis del dominio 


En el Capítulo 21 se describía el enfoque general del 
análisis del dominio en el contexto de la ingeniería del 
software orientado a objetos. Las pasos del proceso se 
definían de la siguiente manera: 


1. Definir el dominio que hay que investigar. 
2. Categorizar los elementos extraídos del dominio. 


3. Recoger una muestra representativa de las aplica- 
ciones del dominio. 


4. Analizar cada aplicación de la muestra. 
5. Desarrollar un modelo de análisis para los objetos. 


Es importante tener en cuenta que el análisis del 
dominio se puede aplicar a cualquier paradigma de la 
ingeniería del software, siendo posible aplicarlo tanto 
para el desarrollo convencional como para el desarro- 
llo orientado a objetos. 

Prieto-Diaz[PRI87] amplíael segundo paso del aná- 
lisis del dominio indicado anteriormente y sugiere un 
enfoque de ocho pasos para la identificación y clasifi- 
cación de componentes reutilizables: 
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1. Seleccionar funciones y objetos específicos. 
2. Abstraer funciones y objetos. 

3. Definir una taxonomía. 

4. Identificar las características comunes. 

5. Identificar las relaciones específicas. 

6. Abstraer las relaciones. 

7. Derivar un modelo funcional. 

$. 


Definir un lenguaje del dominio. 


¿Cómo se pueden identificar 
y clasificar los componentes 
reutilizables? 


El lenguaje del dominio hace posible la especifica- 
ción y construcción posterior de aplicaciones dentro del 
dominio. 

Aun cuando los pasos indicados anteriormente pro- 
porcionan un modelo Útil para el análisis del dominio, no 
proporcionanninguna guía para decidir cuáles son los com- 
ponentes de software que son candidatos para la reutiliza- 
ción. Hutchinson y Hindley [HUT88] sugieren el siguiente 
conjunto de cuestiones pragmáticas como guía para iden- 
tificar los componentes del software reutilizables: 


¿Es la funcionalidad del componente un requisito 
para futuras implementaciones ? 


¿Hasta qué punto es corriente la función del com- 
ponente dentro del dominio? 


¿Existe una duplicación de la función del compo- 
nente dentro del dominio? 


¿Depende ese componente del hardware? 


¿Permanece intacto el hardware entre implementa- 
ciones? 


¿Cuáles son 

los componentes 
identificados durante el análisis 
del dominio que serán candidatos 
de la reutilización? 


¿Es posible trasladar las partes específicas del hard- 
ware a otro componente? 

¿Está el diseño suficientemente optimizado para la 
siguiente implementación? 

¿Es posible parametrizar un componente no reutili- 
zable para que pase a ser reutilizable? 


¿Es reutilizable ese componente en muchas imple- 
mentaciones con cambios solo menores? 


¿Es viable la reutilización mediante modificaciones? 
¿Se puede descomponer un componente no reutili- 
zable para producir componentes reutilizables? 


¿Hasta qué punto es válida la descomposición del 
componente para su reutilización? 
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Una descripción en profundidad de los métodos de 
análisis del dominio va más allá del alcance de este libro. 
Para más información acerca del análisis del dominio, 
véase [PRI193]. 


27.3.2, Funciones de caracterización 


A veces resulta difícil determinar si un componente poten- 
cialmente reutilizable es realmente aplicable en una situa- 
ción determinada. Para llevar a cabo esta determinación, 
es necesario definir un conjunto de características del 
dominio que sean compartidas por todo el softwareen el 
seno del dominio. Una característica del dominio define 
algún atributo genérico de todos los productos que exis- 
ten dentro del dominio. Por ejemplo, entre las caracte- 
rísticas genéricas se podría incluir: la importancia de la 
seguridad y fiabilidad, el lenguaje de programación, la 
concurrencia de procesamiento, y muchas más. 

Un conjunto de características de dominio de un com- 
ponente reutilizable se puede representar como (D,) en 
donde cada elemento D,, del conjunto representa una 
característica específica de dominio. El valor asignado 
aD,,representa una escala ordinal como una indicación 
dela relevancia de esa característicapara el componente 
p. Una escala típica [BAS94] podría ser: 


1. no es relevante para que la reutilización sea O no ade- 
cuada. 


2. relevante sólo en circunstancias poco comunes. 


3. relevante: el componente se puede modificar para 
poder utilizarlo, a pesar de las diferencias. 


Producto Proceso Personal 
Estabilidad Modelo Motivación 
de requisitos de proceso 

Software Ajuste Educación 
concurrente del proceso 

Restricciones Entorno Experiencia/ 
de memoria del proyecto formación 
Tamaño Restricciones e dominio 

de aplicaciones de planificación de aplicación 
Complejidad Restricciones e proceso 

de interfaz de presupuesto 

de usuario 

Lenguaje(s) Productividad e plataforma 
de programación 

Seguridad e lenguaje 

y fiabilidad 

Requisitos Productividad 
de la duración global del equipo 


de desarrollo 
Calidad del producto 
Fiabilidad 
del producto 


TABLA 27.1. Características del dominio que afectan 
al software [BAS94]. 
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4. claramenterelevante, y si el software nuevo no posee 
esta característica, la reutilización será ineficiente 
pero quizás siga siendo posible 

5. es claramente relevante, y si el software nuevo no 
posee esta característica, la reutilización será inefi- 
ciente y la reutilización sin esta característica no es 
recomendable. 


Cuando se va a construir un software nuevo, w,den- 
tro del dominio de la aplicación, se deriva para él un 
conjunto de característicasdel dominio. A continuación, 
se efectúa una comparación entre Di y D,,¡, para deter- 
minar si el componentep se puede reutilizar eficazmente 
en la aplicación w. 


Referencia Web 


Para encontrar referencias valiosas sobre 

una tecnología de objetos de direccionamiento 

de informes, arquitecturas y análisis de dominios, 

se puede visitar la dirección de Internet: 
www.sei.cmu.edu/mbse/ wisr_report.html 


La Tabla 27.1 [BAS94] enumera las características 
típicas del dominio que pueden tener impacto en la reu- 
tilización del software. Estas características del domi- 
nio deben de tenerse en cuenta con objeto de reutilizar 
un componente de forma eficiente. 

Aun cuando el software que se vaya a construir exis- 
ta claramente en el seno de un dominio de aplicación, 
los componentes reutilizables situados dentro de ese 
dominio deberán ser analizados con objeto de determi- 
nar su aplicabilidad. En algunos casos (esperemos que 
sea un número limitado), la «reinvención de la rueda» 
puede seguir siendo la opción más rentable. 


27.3.3. Modelado estructural y puntos de estructura 


Cuando se aplica el análisis del dominio, el analista bus- 
ca tramas repetidas en las aplicaciones que residen den- 
tro del dominio. El modelado estructural es un enfoque 
de ingeniería basado en tramas que opera efectuando la 
suposición consistente en que todo dominio de aplicación 
posee tramas repetidas (de función, de datos y de com- 
portamiento) que tienen un potencial de reutilización. 

Pollak y Rissman [POL94] describen los modelos 
estructurales de la siguiente manera: 

Los modelos estructurales constan de un pequeño número 
de elementos estructurales que manifiestan unas tramas de 
interacción claras. Las arquitecturasde sistemas que utilizan 
modelos estructuralesse caracterizan por múltiplesensambla- 
jes formados por estos elementos del modelo. De esta mane- 
ra, las interacciones complejas entre sistemasque tienen muchas 
unidades arquitectónicas,surgen de tramas sencillas de inte- 
racción que existenen el conjunto pequeño de elementos. 


Todo dominio de aplicación se puede caracterizar 
por un modelo estructural (por ejemplo, la aviónica difie- 
re mucho en los aspectos específicos, pero todo el soft- 


www.elsolucionario.net 


INGENIERÍA DEL SOFTWARE. .., 


ULA LA A LAA 


ware moderno de este dominio tiene el mismo modelo 
estructural). Por tanto, el modelo estructural es un esti- 
lo arquitectónico (Capítulo 14)que puede y debe reuti- 
lizarse en aplicaciones pertenecientes al dominio. 

McMahon [MCM95] describe un punto de estruc- 
tura como una «estructura bien diferenciada dentro de 
un modelo estructural». Los puntos de estructura tienen 
tres características bien claras: 


1. Un punto de estructura es una abstracción que debe 
de tener un número limitado de instancias. Al replan- 
tear esta característica en lajerga orientada a obje- 
tos (Capítulo 20), el tamaño de la jerarquía de clases 
debe ser pequeño. Además, la abstracción debe repe- 
tirse a lo largo de las aplicaciones del dominio. En 
caso contrario, el esfuerzo requerido para verificar, 
documentar y diseminar ese punto de estructura no 


puede justificarse en términos de coste. 
¿Qué es un «punto 


? de estructura)) y cuáles 
son sus características? 


La reglas que rigen la utilización del punto de estruc- 
tura deben entenderse fácilmente. Además, la inter- 
faz con el punto de estructura debe ser relativamente 
sencilla. 

. El punto de estructura debe implementar el oculta- 
miento de información aislando toda la complejidad 
dentro del punto de estructura en sí. Esto reduce la 
complejidad percibida del sistema en su conjunto. 


Como ejemplo de puntos de estructura como tramas 
arquitectónicas para un sistema, considérese el domi- 
nio del software de sistemas de alarma. El dominio del 
sistema puede abarcar sistemas tan simples como 
HogarSeguro (descritos en capítulos anteriores) O tan 
complejos como el sistema de alarma de un proceso 
industrial. Sin embargo, se encuentran un conjunto de 
tramas estructurales predecibles: 

+ Una interfaz que capacita al usuario para interactuar 
con el sistema; 


un mecanismo de establecimiento de límites que per- 
mite al usuario establecer límites sobre los paráme- 
tros que hay que medir; 


un mecanismode gestión de sensores que se comunica 
con todos los sensores empleadosen la monitorización; 


un mecanismo de respuesta que reacciona frente a 
las entradas proporcionadas por el sistema de ges- 
tión de sensores; 


un mecanismo de control que capacita al usuario 
para controlar la forma en que se efectúa la moni- 
torización. 


e, 
CLA VE 


Un punto de estructura se puede ver como un patrón 
de diseño que aparece repetidas veces en aplicaciones 
dentro de un dominio específico. 


Cada uno de estos puntos de estructura está integra- 
do en una arquitectura de dominio. 

Es posible definir los puntos de estructura genéricos 
que trascienden a un número de dominios de aplicacio- 
nes diferentes [STA94]: 


Aplicaciones cliente. La IGU, que incluye todos los mentís, 
paneles y capacidades de entrada y edición de órdenes. 


Bases de datos. El depósito de todos los objetos relevantes 
para el dominio de la aplicación 


Motores de cálculo. Los modelos numéricos y no numéri- 
cos que manipulan datos. 


Función de reproducciónde informes. La función que pro- 
duce salidas de todo tipo. 


Editor de aplicaciones. Mecanismo adecuado para perso- 
nalizar la aplicación ajustándola a las necesidades de usuarios 
específicos. 


Los puntos de estructura se han sugerido como alter- 
nativa a las líneas de código y a los puntos de función 
para la estimación del coste del software ([MCM95]. 
En la Sección 27.6.2 se presenta una descripción breve 
del coste utilizando puntos de estructura. 


—27.4 DESARROLLO BASADO EN COMPONENTES. ————— 


El desarrollo basado en componentes es una actividad 
de la ISBC que tiene lugar en paralelo a la ingeniería 
del dominio. La utilización de métodos de diseño arqui- 
tectónico y de análisis se ha descrito anteriormente en 
otra sección de este texto, en donde el equipo del soft- 
ware refina el estilo arquitectónico adecuado para el 
modelo de análisis de la aplicación que se va a cons- 
truir”. 


? Se debería destacar que el estilo arquitectónico suele estar influen- 
ciado por el modelo de estructura genérico creado en la ingeniería 
del dominio (véase Figura 27.1) 
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Una vez que se ha establecidola arquitectura, se debe 
popularizar mediante los componentes que (1) están dis- 
ponibles en bibliotecas de reutilización, y/o (2) se han 
diseñado para satisfacer las necesidades del cliente. De 
aquí que el flujo de una tarea de desarrollo basada en 
componentes tenga dos caminos posibles (Fig. 27.1). 
Cuando los componentes reutilizables están disponibles 
para una integración futura en la arquitectura, deben 
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estar cualificadosy adaptados. Cuando se requieren com- 
ponentes nuevos, deben diseñarse. Los componentes 
resultantes entonces se «componen» (se integran) en una 
plantilla de arquitectura y se comprueban a conciencia. 


27.4.1. Cualificación, adaptación y composición 
de componentes 


Como se acaba de ver, la ingeniería del dominio propor- 
ciona la biblioteca de componentes reutilizables necesa- 
rios para la ingeniería del software basada en componentes. 
Algunos de estos componentes reutilizables se desarro- 
llan dentro de ella misma, otros se pueden extraer de las 
aplicaciones actuales y aun otros se pueden adquirir de 
terceras partes. 

Desgraciadamente, la existencia de componentes reu- 
tilizables no garantiza que estos componentes puedan 
integrarsefácilmente, o de forma eficaz, en la arquitec- 
tura elegida para una aplicación nueva. Esta es la razón 
por la que se aplica una sucesión de actividadesde desa- 
rrollo basada en componentes cuando se ha propuesto 
que se utilice un componente. 


Cualificación de componentes 


La cualificación de componentes asegura que un com- 
ponente candidato llevará a cabo la función necesaria, 
encajará además «adecuadamente» en el estilo arqui- 
tectónico especificado para el sistema y exhibirá las 
características de calidad (por ejemplo,rendimiento, fia- 
bilidad, usabilidad) necesarias para la aplicación. 

La descripción de la interfaz proporciona informa- 
ción útil sobre la operación y utilización de los compo- 
nentes del software, pero no proporciona toda la 
información necesaria para determinar si un componente 
propuesto puede de hecho volver a reutilizarse de mane- 
ra eficaz en una aplicación nueva. A continuación, se 
muestran algunos factores de los muchos a tener en cuen- 
ta durante la cualificación de los componentes [BRO96]: 


la interfaz de programación de aplicaciones (APD); 


las herramientas de desarrollo e integración necesa- 
rias para el componente; 


requisitos de ejecución, entre los que se incluyen la 


utilización de recursos (por ejemplo, memoria o alma- 
cenamiento), tiempo o velocidad y protocolo de red; 


¿Cuáles son los factores 
a tener en cuenta durante 
la cualificación de componentes? 


requisitos de servicio, donde se incluyen las interfa- 
ces del sistema operativo y el soporte por parte de 
otros componentes; 

funciones de seguridad, como controles de acceso y 
protocolo de autenticación; 

supuestos de diseños embebidos, incluyendo la uti- 
lización de algoritmos numéricos y no numéricos; 


manipulación de excepciones. 


UNTILUWW cr 
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Cada uno de los factores anteriores es relativamen- 
te fácil de valorar cuando se proponen los componen- 
tes reutilizables que se han desarrollado dentro de la 
misma aplicación. Si se han aplicado prácticas de inge- 
niería del software de buena calidad durante el desa- 
rrollo, se pueden diseñar respuestas para las preguntas 
relacionadas con la lista anterior. Sin embargo, es mucho 
más difícil determinar el funcionamiento interno de com- 
ponentes CYD o de terceras partes, porque la Única 
información disponible es posible que sea la misma 
interfaz de especificaciones. 


Adaptación de componentes 


Lo ideal sería que la ingeniería del dominio creara una 
biblioteca de componentes que pudieran integrarse fácil- 
mente en una arquitectura de aplicaciones. La implica- 
ción de una «integración fácil» es que: (1) se hayan 
implementado los métodos consecuentes de la gestión de 
recursos para todos los componentes de la biblioteca; (2) 
que existan actividades comunes, tales como la gestión 
de datos para todos los componentes, y (3) que se hayan 
implementado interfaces dentro de la arquitectura y con 
el entorno externo de manera consecuente. 


En realidad, incluso después de haber cualificado 
un componente para su utilización dentro de una arqui- 
tectura de aplicación, es posible exhibir conflictos en 
una O más de las áreas anteriores. Para mitigar estos 
conflictos se suele utilizar una técnica de adaptación 
llamada «encubrimiento de componentes» [BRO96]. 
Cuando un equipo de software tiene total acceso al dise- 
ño interno y al código de un componente (no suele ser 
el caso de los componentes CY D) se aplica el encu- 
brimiento de caja blanca. Al igual que su homólogo en 
las pruebas del software (Capítulo 17), el encubrimiento 
de caja blanca examina los detalles del procesamien- 
to interno del componente y realiza las modificaciones 
a nivel de código para eliminar los conflictos. El encu- 
brimiento de caja gris se aplica cuando la biblioteca 
de componentes proporciona un lenguaje de extensión 
de componentes, O API, que hace posible eliminar o 
enmascarar los conflictos. El encubrimiento de caja 
negra requiere la introducción de un preprocesamien- 
to O postprocesamiento en la interfaz de componentes 
para eliminar o enmascarar conflictos. El equipo de 
software debe determinar si se justifica el esfuerzo 
requerido para envolver adecuadamente un componente 
O si por el contrario se debería diseñar un componente 
personalizado (diseñado para eliminar los conflictos 
que se encuentren). 


www.elsolucionario.net 


INGENIERÍA DEL SOFTWARE. U 


iv aura UN VAL ara 


Composición de componentes 


La tarea de composición de componentes ha ensam- 
blado componentes cualificados, adaptados y diseña- 
dos para popularizar la arquitectura establecida para. 
una aplicación. Para poder llevarlo a cabo, debe esta- 
blecerse una infraestructura donde los componentes 
estén unidos a un sistema operacional. La infraestruc- 
tura (normalmenteuna biblioteca de componentes espe- 
cializados) proporciona un modelo para la coordinación 
de componentes y servicios específicos que hacen posi- 
ble coordinar unos componentes con otros, y llevar a 
cabo las tareas comunes. 

Entre los muchos mecanismos para crear una infraes- 
tructura eficaz, existe un conjunto de cuatro «ingre- 
dientes arquitectónicos» [ADL95] que se debería 
presentar para lograr la composición de componentes: 


Modelo de intercambio de datos. Setrata de mecanismos 
que capacitan a los usuarios y a las aplicaciones para interac- 
tuar y transferir datos (por ejemplo, arrastrar y soltar, cortar y 
pegar), y que deberían estar definidos para todos los compo- 
nentes reutilizables. Los mecanismos de intercambio de datos 
no solamente permiten la transferencia de datos entre hombre 
y programa, y entre componentes, sino que también hacen posi- 
ble la transferencia entre los recursos del sistema (por ejem- 
plo, arrastrar un archivo al icono de una impresora para 
imprimirlo). 


Automatización. Para facilitar la interacción entre com- 
ponentes reutilizables se deberían de implementar herramien- 


tas, macros y guiones. 
2 ¿Cuales son los ingredientes 
necesarios para lograr 
la composiciónde componentes? 


Almacenamiento estructurado. Los datos heterogéneos 
(por ejemplo, los datos gráficos, de voz, texto, vídeo y datos 
numéricos)dentro de un «documentocompuesto», deben estar 
organizados para poder acceder a ellos como si de una sola 
estructura de datos se tratase, en lugar de comportarse como si 
fueran toda una colección de archivos por separado. «Los datos 
estructurados mantienen un índice descriptivo de estructuras 
de anidamiento, que las aplicaciones pueden recorrer libre- 
mente para localizar,crear o editar el contenido de datos indi- 
viduales según lo indique el usuario final» [ADL95]. 


Modelo de objetos subyacente.El modelo de objetos ase- 
gura que los componentes desarrolladosen distintos lenguajes 
de programación que residan en distintas plataformas pueden 
ser interoperables. Esto es, los objetos deben ser capaces de 
comunicarse en una red. Para lograr esto, el modelo de obje- 
tos define un estándar para la interoperabilidadde los compo- 
nentes. 


Dado que el impacto futuro de la reutilización y de 
la ISBC en la industriadel softwarees enorme, una gran 
cantidad de empresas importantes y consorcios indus- 
triales* han propuesto estándares para el software por 
componentes: 


3 En [ORF96] y [YOU98] se presenta un estudio excelente sobre los 
estándares de «objetos distribuidos», 
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OMG/CORBA, El Grupo de gestión de objetos (Object 
Management Group) ha publicado una arquitectura común de 
distribución de objetos(OMG/CORBA). Los distribuidoresde 
objetos (ORB) proporcionan toda una gama de servicios que 
hacen posible que los componentes reutilizables (objetos) se 
comuniquen con otros componentes, independientemente de 
su ubicación dentro del sistema. Cuando se construyen com- 
ponentes empleando el estándar OMG/CORBA, la integración 
deesos componentes(sin modificación) dentro del sistema que- 
da garantizada si se crea una interfaz mediante un lenguaje de 
definiciónde interfaces(LDI) para cada componente. 


Referencia Web 


La información más actualizada sobre CORBA se puede 
obtener en WWW.OMQ.Org 


Utilizando una metáfora cliente/servidor, los objetos situa- 
dos dentro de la aplicación cliente solicitan uno o más ser- 
vicios del servidor de ORB. Las solicitudes se hacen a través 
del LDI, o bien dinámicamente en el momento de la ejecu- 
ción. Un repositorio de interfaces contiene toda la informa- 
ción necesaria acerca de las solicitudes de servicio y de los 
formatos de respuesta. CORBA se estudia con más detalle 
en el Capítulo 28. 


COM de Microsoft. Microsoft ha desarrollado un mode- 
lo de objetos para componentes (COM) que proporciona una 
especificación para utilizar los componentes elaborados por 
diferentes fabricantes dentro de una aplicación única bajo el 
sistema operativo Windows. COM abarca dos elementos: las 
interfaces COM (irnplementadas como objetos COM) y un 
conjunto de mecanismos para registrar y pasar mensajes entre 
interfaces COM. Desde el punto de vista de la aplicación, «el 
foco no está en cómo [seimplementan los objetos COM], sino 
en el hecho de que el objeto tiene una interfaz que se registra 
con el sistema, y que utiliza el sistema de componentes para 
comunicarse con otros objetos COM» [HAR98]. 


Referencia 


La información más actualizada sobre OCM se puede 
obtener en www.microsoft.com/COM 


Componentes JavaBean de SUN. El sistema de compo- 
nentes JavaBean es una infraestructura ISBC portátil e inde- 
pendiente de la plataforma que utiliza el lenguaje de 
programación Java. El sistema JavaBean amplía el applef' de 
Java para acoplar los componentes de software más sofistica- 
dos necesarios para el desarrollo basado en componentes. 


Referencia Web 


Para obtener recursos excelentes de estimación 
visite la Red de Gestores de Proyectosen 
java.sun.com/beans 


* En este contexto, un applet se puede considerar un componente 
simple. 
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El sistema de componentes JavaBean acompaña un con- 
junto de herramientas llamadas Kit de Desarrollo Bean (BDK), 
que permite a los desarrolladores: (1) analizarel funcionamiento 
de los Beans (componentes); (2)personalizar su comporta- 
miento y aspecto; (3)establecer mecanismos de coordinación 
y comunicación; (4)desarrollar Beans personalizados para su 
utilización en una aplicación específica; y (5) probar y evaluar 
el comportamiento de un Bean. 


¿Cuál de estos estándares dominará la industria? Por 
el momento, no hay una respuesta fácil. Aunque muchos 
desarrolladores han establecido normas en base a uno 
de estos estándares, es probable que grandes empresas 
de software tengan la posibilidad de elegir entre tres 
estándares, dependiendo de las categorías y plataformas 
de aplicación que hayan seleccionado. 


27.4.2, Ingeniería de componentes 


Como se ha señalado anteriormente en este capítulo, el 
proceso de ISBC fomenta la utilización de los compo- 
nentes de software existentes. Sin embargo, hay oca- 
siones en que se deben diseñar los componentes. Es 
decir, los componentes de software nuevos deben desa- 
rrollarsee integrarse con los componentes CYD ya exis- 
tentes y los de desarrollo propio. Dado que estos 
componentes nuevos van a formar parte de la bibliote- 
ca de desarrollo propio de componentes reutilizables, 
deberían diseñarse para su reutilización. 

No hay nada de mágico en la creación de compo- 
nentes de software que se pueden reutilizar. Conceptos 
de diseño tales como abstracción, ocultamiento, inde- 
pendencia funcional, refinamiento y programación estruc- 
turada, junto con los métodos orientados a objetos, 
pruebas, SQA y métodos de verificación de corrección, 
todos ellos contribuyen a la creación de componentes de 
software que son reutilizables'. En esta sección no se 
revisarán estos temas, sino que, por el contrario, se ten- 
drán en consideración los temas específicos de la reuti- 
lización para prácticas sólidas de ingeniería del software. 


2743. Análisis y diseño para la reutilización 


Los componentes de diseño y análisis se han tratado 
detalladamente en las Partes Tercera y Cuarta de este 
libro. Los modelos de datos, funcional y de comporta- 
miento (representados mediante una gama de notacio- 
nes distintas) se pueden crear con objeto de describir lo 
que debe realizar una determinada aplicación. A conti- 
nuación, se utilizan unas especificaciones por escrito 
para describirestos modelos, y obtener como resultado 
final una descripción completa de los requisitos. 

Lo ideal sería analizar el modelo de análisis para 
determinar aquellos elementos del modelo que indican 
unos componentes reutilizables ya existentes. El pro- 
blema consiste en extraerinformación a partir del mode- 
lo de requisitos, de forma que pueda llevar a una 


$ Para aprender más sobre estos temas, véase desde el Capítulo 13 
hasta el 16, y desde el 20 al 22. 
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«correspondenciade especificaciones».Bellinzoni y sus 
colaboradores [BEL95] describen un enfoque para los 
sistemas orientados a objetos: 


Los componentes se definen y se almacenan como clases 
de especificación, diseñoe implementación con diferentesnive- 
les de abstracción (cada clase es una descripción ya realizada 
de un producto procedente de aplicacionesanteriores). El cono- 
cimiento de especificación -conocimiento de desarrollo— 
se almacenaen la forma de clases que sugieren lareutilización, 
y quecontienenindicacionespara recuperar componentesreu- 
tilizables basándose en su descripción y también para compo- 
nerlos y ajustarlos una vez recuperados. 


Coso. 


Aunque la empresano haga ingeniería de dominios, 

hay que ir realizándola amedida que avanza el trabajo. 
Cuandoconstruya elmodelo de análisispregúntese: 
«¿Esprobable que esteobjeto a función se pueda encontrar 
enotras aplicaciones de este tipo?» Sila respuesto 
esafirmativa, puede que el componente ya existo. 


Las herramientas automatizadas se utilizan para 
explorar el repositorio en un intento de hacer coinci- 
dir el requisito indicado en la especificación actual con 
los descritos para unos componentes reutilizables ya 
existentes (clases). Las funciones de caracterización 
(Sección 27.3.2) y las palabras reservadas se emplean 
como ayuda para hallar componentes potencialmente 
reutilizables. 

Si la correspondencia de especificaciones produce 
componentes que se ajustan a las necesidades de la 
aplicación en cuestión, el diseñador puede extraer 
estos componentes de una biblioteca de reutilización 
(repositorio) y utilizarlos para diseñar el nuevo siste- 
ma. Sino es posible hallar componentes de diseño, el 
ingeniero del software entonces debe aplicar métodos 
de diseño convencionales u OO para crearlos. Es en 
este momento - cuando el diseñador comienza a crear 
un nuevo componente — en el que debe de conside- 
rarse el diseño para la reutilización (DPR). 


Cons 


Aunque existen asuntos especialesa tener en cuenta 
cuando el objetivo es la reutilización, hay que centrarse 
en las principios básicos de un buen diseño. Sise siguen 
estos principias, las probabilidadesde reutilización 
aumentarán significotivomente. 


Tal como se ha indicado anteriormente, el DPR 
requiere que el ingeniero del software aplique unos sóli- 
dos conceptos y principios de diseño del software (Capí- 
tulo 13). Pero las características del dominio de la 
aplicación también tienen que tenerse en cuenta. Bin- 
der [BIN93] sugiere un cierto número de asuntos' fun- 


$ En general las preparaciones indicadas para el diseño destinado a 
la reutilización deberían de llevarse a cabo como parte de la inge- 
niería del dominio (Sección 27.3). 


www.elsolucionario.net 


INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRACTICO 


damentales que deben considerarse como base del dise- 
ño para la reutilización: 


Datos estándar. Es preciso investigarel dominio de la apli- 
cación, y es preciso identificar las estructuras de datos están- 
dar globales (por ejemplo, las estructuras de archivos o toda 
una base de datos completa). Entonces se pueden caracterizar 
todos los componentes de diseño para uso de estas estructuras 
de datos estándar. 


Protocolos de interfaz estándar. Deberían establecerse tres 
niveles de protocolo de interfaz: la naturaleza de las interfaces 
intramodulares, el diseño de interfaces técnicas externas (no 
humanas) y la interfaz hombre-máquina. 


Plantillas de programa. El modelo de estructura (Sección 
27.3.3) puede servir como plantilla para el diseño arquitectó- 
nico de un nuevo programa. 


Una vez que se han establecido los datos estándar, 
las interfaces y las plantillas de programa, el diseñador 
posee un marco de referencia en el cual puede crear el 
diseño. Los componentes nuevos que se ajustan a este 
marco de referencia tendrán una mayor probabilidad de 
ser posteriormente reutilizables. 

Al igual que el diseño, la construcción de compo- 
nentes reutilizables se basa en métodos de la ingeniería 
del software que ya se han descrito en otras partes de 
este libro. La construcción se puede efectuar emplean- 
do lenguajes convencionales de programación, de ter- 
cera generación, lenguajes de cuarta generación y 
generadores de código, técnicas de programación visual 
O herramientas más avanzadas. 


Considere una gran biblioteca universitaria. Para su 
utilización tiene disponibles decenas de millares de 
libros, periódicos y otras fuentes de información. 
Ahora bien, para acceder a estos recursos es preciso 
desarrollar algún sistema de clasificación. Para reco- 
rrer este gran volumen de información, los bibliote- 
carios han definido un esquema de clasificación que 
incluye un código de clasificación de la biblioteca, 
palabras reservadas, nombres de autor y otras entra- 
das de índice. Todas ellas capacitan al usuario para 
encontrar el recurso necesario de forma rápida y sen- 
cilla. 


+ 


sspués de conocer algo, 
Je se encuentra. 


Considere ahora un gran depósito de componentes. 
Residen en él decenas de millares de componentes de 
software reutilizables. ¿Cómo puede hallar el ingenie- 
ro del software el componente que necesita? Para res- 
ponder a esta pregunta, surge otra pregunta más. ¿Cómo 
se describen los componentes de software en términos 
de no ambiguos y fácilmente clasificables? Se trata de 
cuestiones difíciles y todavía no se ha desarrollado una 
respuesta definitiva. En esta sección, se exploran las ten- 
dencias actuales que capacitarán a los futuros ingenie- 
ros del software para navegar por las bibliotecas 
reutilizables. 


27.511. Descripción de componentes reutilizables 


Un componente de software reutilizable se puede des- 
cribir de muchas maneras, pero la descripción ideal abar- 
ca lo que Tracz [TRA90] ha llamado el Modelo 3C 
-concepto, contenido y contexto—. 
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El concepto de un componente de software es una 
«descripción de lo que hace el componente» [WHI95]. 
La interfaz con el componente se describe completa- 
mente y su semántica — representada dentro del con- 
texto de pre y postcondiciones — se identifica también. 
El concepto debe comunicar la intención del compo- 


nente. 


“3 
LAVE 


Poro describir un componente reutilizable, se tendrá 
que describir su concepto, contenido y contexto. 


El contenido de un componente describe la forma en 
que se construye el concepto. En esencia, el contenido 
es una información que queda oculta a los ojos del usua- 
rio habitual y que solamente necesita conocer quien 
intentará modificar ese componente. 

El contexto sitúa el componente de software reutili- 
zable en el seno de su dominio de aplicabilidad, esto es, 
mediante la especificación de características concep- 
tuales, operacionales y de implementación, el contexto 
capacita al ingeniero del software para hallar el com- 
ponente adecuado para satisfacer los requisitos de la 
aplicación. 


Referencia 


Uno detallado guía de reutilización de componentes 
se puede descargar de la dirección 

webl .ssg.gunter.af.mil/ 
sep/SEPver40/Main.html*GD 


Para que resulte útil en un sentido práctico, el con- 
cepto, el contenido y el contexto tienen que traducirse 
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en un esquema de especificaciónconcreto. Se han escri- 
to varias docenas de artículos y trabajos acerca de los 
esquemas de clasificación para componentes de soft- 
ware reutilizables (por ejemplo, [WH195] contiene una 
extensa bibliografía). Los métodos propuestos se pue- 
den descomponer en tres zonas fundamentales: méto- 
dos de las ciencias de la documentación y de 
biblioteconomía, métodos de inteligenciaartificial y sis- 
temas de hipertexto. La gran mayoría de los trabajos 
realizados hasta el momento sugiere la utilización de 
métodos propios de biblioteconomía para la clasifica- 
ción de componentes. 

La Figura 27.2 presenta una taxonomía de los méto- 
dos de indexación en biblioteconomía. Los vocabula- 
rios controlados de indexación limitan los términos y 
sintaxis que se pueden utilizar para clasificar los obje- 
tos (componentes). Los vocabularios de indexación no 
controlados no imponen restricciones sobre la naturale- 
za de la descripción. La gran mayoría de los esquemas 
de clasificación para los componentes de software se 
encuentran dentro de las tres categorías siguientes: 

Clasificación enumerada. Los componentes se describen 
mediante la definición de una estructurajerárquica en la cual 
se definen clases y diferentes niveles de subclases de compo- 
nentes de software. Los componentes en sí se enumeran en el 
nivel más bajo de cualquierruta de lajerarquía enumerada. Por 


ejemplo, una jerarquía enumerada para operaciones con ven- 
tanas” podríaser 


operaciones ventana 
visualización 
abrir 
basados en menú 
ventanaAbierta 
basados en sistemas 
ventanaSis tema 
cerrar 
a través de puntero 


cambio de tamaño 
a través de órdenes 


establecerTamVentana, redimensionadoEs- 
tandar, contraerventana 

por arrastre 
arrastrarVentana, estirarVentana 


reordenación de planos 
desplazamiento 


cierre 


La estructurajerárquicade un esquema de clasificación enu- 
merado hace que sea sencillo comprenderlo y utilizarlo. Sin 
embargo, antes de poder construiruna jerarquía, es preciso lle- 
vara cabo una ingenieríadel dominio para que esté disponible 
una cantidad suficientede conocimientos acerca de las entra- 
das correctas de esajerarquía. 


7 Solamente se indica un pequeño subconjunto de todas las opera- 
ciones posibles. 
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Vocabulario 
de indexación 


Controlados 
sn Palabra 
Clasificado 
Encabezados 

del tema 


FIGURA 27.2”. Una taxonomía de métodos de indexación 
[FRA9A]. 


incontrolados 


Términos 
no extraídos 
del texto 


Términos 
extraídos 
del texto 


Sin sintaxis 


Enumeración 


Clasificación por facetas. Se analiza una cierta área del 
dominio y se identificaun conjunto de características descrip- 
tivas básicas. Estas características, que se denominan facetas, 
reciben entonces diferentes prioridades según su importanciay 
se relacionan con un componente. La faceta puede describir la 
función que lleva a cabo el componente, los datos que se mani- 
pulan, el contexto en que se aplican o cualquierotra caracterís- 
tica. El conjunto de facetas que describen los componentes se 
denomina descriptor de facetas. Generalmente, la descripción 
por facetas se limita a un máximo de sieteu ocho facetas. 


¿Cuáles son las opciones 
disponibles para clasificar 
componentes? 


Comoilustración sencilla del uso de facetas en la clasifica- 
ción de componentes, considérese un esquema [LIA93] que 
hace uso del siguiente descriptor de facetas: 


(función, tipo de objeto, tipo de sistema) 


Cada una de las facetas del descriptorde facetas adopta uno 
o más valores que en general serán palabras reservadas des- 
criptivas. Por ejemplo, si función es una faceta de un compo- 
nente, entonces entre los valores típicos que se asignan a esta 
faceta podríamos contar: 
función = (copiar, desde) o bien (copiar, reemplazar, 
todo) 


La utilización de múltiples valores de faceta hace posible 
que la función primitiva copiar se refine más exactamente. 


Las palabras reservadas (valores) se asignan al conjunto de 
facetas de cada componente de una cierta biblioteca de reutili- 
zación. Cuandoun ingeniero del softwaredesea ocultar labiblio- 
teca en busca de posibles componentes para un diseño, se 
especifica una lista de valores y se consultala biblioteca en bus- 
ca de posibles candidatos. Para incorporar una función de dic- 
cionario se pueden emplear herramientas automatizadas. Esto 
hace posible que la búsqueda no sólo abarquelas palabras reser- 
vadas especificadaspor el ingeniero del software, sino también 
otros sinónimos técnicos de esas mismas palabras reservadas. 
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Un esquema de clasificación por facetas proporcionaalinge- 
niero del dominio una mayor flexibilidad al especificar des- 
criptores complejos de los componentes [FRA94]. Dado que 
es posible añadir nuevos valores de facetas con facilidad, el 
esquema de clasificación por facetas es más fácil de extender 
y de adaptar que el enfoque de enumeración. 


Clasificaciónde atributos y valores. Para todos los com- 
ponentes de una cierta zona del dominio se define un conjun- 
to de atributos. A continuación, se asignan valores a estos 
atributos de forma muy parecida a una clasificación por face- 
tas. De hecho, la clasificación de atributos y valores es pareci- 
da ala clasificaciónpor facetas con las excepcionessiguientes: 
(1) no hay límite para el número de atributos que se pueden 
utilizar; (2) no se asignan prioridades a los atributos; y (3) no 
se utiliza la función diccionario. 


Basándose en un estudioempírico de cada una de las 
técnicas anteriores de clasificación, Frakes y Pole [FRA94] 
indican que no existe una técnica que sea claramente«la 
mejor» y que «ningúnmétodo es más que moderadamente 
adecuado en lo tocante a efectividad de búsqueda....». 
Parece entonces que es preciso realizar un trabajo más 
extenso en el desarrollo de unos esquemas de clasifica- 
ción efectivos para las bibliotecas de reutilización. 


27.52. El entorno de reutilización 

La reutilización de componentes de software debe de 
estar apoyada por un entorno que abarque los elemen- 
tos siguientes: 

una base de datos de componentes capaz de almace- 
nar componentesde software, asícomo la información 
de clasificación necesaria para recuperarlos. 

un sistema de gestión de bibliotecas que pro- 
porciona acceso a la base de datos. 


un sistema de recuperación de componentes de 
software (por ejemplo, un distribuidor de obje- 


—2 8 ECONOMIA DELAJISEBC 


La economía de la ingeniería del software basada en 
componentes tiene un atractivo evidente. En teoría, 
debería proporcionar a las empresas de software unas 
ventajas notables en lo tocante a la calidad y a los tiem- 
pos de realización. Éstas, a su vez, deberían traducirse 
en ahorros de costes. ¿Existen datos reales que presten 
apoyo a nuestra intuición? 

Para responder a esta pregunta primero es preciso 
comprender lo que se puede reutilizar en un contexto 
de ingeniería del software, y cuáles son los costes aso- 
ciados a la reutilización. Como consecuencia, será posi- 
ble desarrollarun análisis de costes y de beneficios para 
la reutilización. 


27.6.1. Impacto en la calidad, productividad y coste 


A lo largo de los Últimos años, existen notables evi- 
dencias procedentes de casos prácticos en la industria 
(por ejemplo, [HEN95], [MCM9S5] y [LIM94)), las cua- 
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tos) que permite a la aplicación cliente recuperar 
los componentes y servicios del servidor de la 
biblioteca. 


unas herramientas CASE que prestan su apoyo a la 


integración de componentesreutilizadosen un nuevo 
diseño O implementación. 


Cada una de estas funciones interactúa con una 
biblioteca de reutilización o bien se encuentra incorpo- 
rada a esta última. 

La biblioteca de reutilización es un elemento de un 
repositorio CASE más extenso (Capítulo 31) y propor- 
ciona las posibilidades adecuadas para el almacena- 
miento de una amplia gama de elementos reutilizables 
(por ejemplo, especificación, diseño, casos de prueba, 
guías para el usuario). La biblioteca abarca una base de 
datos y las herramientas necesarias para consultar esa 
base de datos y recuperar de ella componentes. Un 
esquema de clasificación de componentes (Sección 
27.5.1) servirá como base para consultas efectuadas a 
la biblioteca. 

Las consultas suelen caracterizarse mediante el uso 
del elemento de contexto del Modelo 3C que se descri- 
bía anteriormente. Si una consulta inicial da lugar a una 
lista voluminosa de candidatos a componentes, enton- 
ces se refina la consulta para limitar esa lista. A conti- 
nuación, se extraen las informaciones de concepto y 
contenido (después de haber hallado los candidatos a 
componentes) para ayudar al desarrollador a que selec- 
cione el componente adecuado. 

Una descripción detallada de la estructura de biblio- 
tecas de reutilización y de las herramientas que las ges- 
tionan va más allá de los límites de este libro. El lector 
interesado debería consultar [HOO91] y [LIN95] para 
más información. 


les indican que es posible obtener notables beneficios 
de negocios mediante una reutilización agresiva del soft- 
ware. Se mejora tanto la calidad del producto, como la 
productividad del desarrollador y los costes en general. 


Cionsuofh 


ISBC no es un «rompe crismas» económico 

si los componentesdisponiblesson /as correctos 
para eltrabajo. Silo reutilizaciónexige 
personalizoción, hoy que proceder con precaución. 


Calidad. En un entorno ideal, un componente del 
software que se desarrolle para su reutilización estará 
verificado en lo tocante a su corrección (véase el Capí- 
tulo 26) y no contendrá defectos. En realidad, la verifi- 
cación formal no se lleva a cabo de forma rutinaria, y 
los defectos pueden aparecer y aparecen. Sin embargo, 
con cada reutilización, los defectos se van hallando y 
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eliminando, y comoresultado la calidad del componente 
mejora. Con el tiempo, el componente llega a estar vir- 
tualmente libre de defectos. 

En un estudio realizado en Hewlet-Packard, Lim 
[LIM94] informa que la tasa de defectos para el código 
reutilizado es de 0,9 defectos por KLDC, mientras que 
la tasa para el software recién desarrollado es de 4,1 
defectos por KLDC. Para que una aplicación esté com- 
puesta por un 68 por 100 de código reutilizado, la tasa 
de defectos será de 2,0 defectos —una mejora del 51 por 
100 para la tasa esperada si la aplicación hubiera sido 
desarrollada sin reutilización —. Henry y Faller [HEN9S] 
informan de una mejora de calidad del 35 por 100.Aun 
cuando existen recortes anecdóticos que abarcan un 
espectrorazonablemente amplioen porcentajes de mejo- 
ra de la calidad, es justo que la reutilización proporcio- 
ne un beneficio no despreciable en función de la calidad 
y fiabilidad del software proporcionado. 


$ 
SS 
e? VE 


Aunque los datos empíricosvarien, la evidencia 
industrial indica que la reutilización proporciona 
un beneficio sustancialen coste. 


Productividad. Cuando se aplican componentesreu- 
tilizables a lo largo del proceso del software, se invierte 
menos tiempo creandolos planes, modelos, documentos, 
código y datos necesarios para crear un sistema fiable. 
Se sigue proporcionandoun mismo nivel de funcionali- 
dad al cliente con menos esfuerzo. Consiguientemente, 
mejora la productividad. Aun cuando los informes acer- 
ca de las mejoras de productividad son sumamente difí- 
ciles de interpretar”, parece que una reutilización de entre 
el 30 y el 50 por 100 puede dar lugar a mejoras de pro- 
ductividad que se encuentren entre el intervalo que media 
entre el 25 y el 40 por 100. 

Coste. El ahorro neto de costes para la reutilización 
se estima proyectando el coste del proyecto si se hubie- 
ra desarrollado éste desde cero, C, y restando después 
la suma de los costes asociados para la reutilización, € a 
y el coste real del software cuando este finalmente se 
implanta, C,. 

C se puede determinar aplicando una o más de las 
técnicas de estimación descritas en el Capítulo 5. Los 


costes asociados a la reutilización, C, incluyen 
[CHR95]: 


+ Modelado y análisis del dominio; 
+ Desarrollo de la arquitectura del dominio; 


$ Existen muchas circunstancias atenuantes (por ejemplo, área de 
aplicación, complejidad del problema, estructura y tamaño del equipo, 
duración del proyecto, tecnología aplicada) que puede tener su 
impacto sobre la productividad del equipo de un proyecto. 


CAPÍTULO 27 INGENIERÍA DEL SOFTWARE BASADA EN COMPONENTES 
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2 ¿Cuales son los tostes 
asociados a la reutilizatión 
del software? 


Incremento de la documentación para facilitar la reu- 
tilización; 

Mantenimiento y mejora de componentes de la reu- 
tilización; 

Licencias para componentes adquiridos externamente; 
Creación O adquisición y funcionamientode un depó- 
sito para la reutilización; 

Formación del personal en el diseño y construcción 
para la reutilización. 


Aun cuando los costes asociados al análisis del domi- 
nio (Sección 27.4) y el funcionamiento de un reposito- 
rio para la reutilización pueden resultar notables, muchos 
de los costes restantes indicados anteriormente se enfren- 
tan con temas que forman parte de las buenas prácticas 
de la ingeniería del software, tanto si se considera prio- 
ritaria la reutilización como si no. 


27.6.2. Análisis de coste empleando puntos 
de estructura 


En la Sección 27.3.3se definía un punto de estructura 
como una trama arquitectónica que aparece repetida- 
mente en el seno de un determinado dominio de apli- 
caciones. El diseñador del software (o el ingeniero del 
sistema) puede desarrollar una arquitectura para una 
nueva aplicación, sistema O producto mediante la defi- 
nición de una arquitectura del dominio y poblándola 
entonces con puntos de estructura. Estos puntos de 
estructura son, O bien componentes reutilizables, o bien 
paquetes de componentes reutilizables. 

Aun cuando los puntos de estructura sean reutiliza- 
bles, su adaptación, integración y costes de manteni- 
miento no serán despreciables. Antes de seguir adelante 
con la reutilización, el gestor del proyecto debe enten- 
der los costes asociados al uso de puntos estructura. 

Dado que todos los puntos de estructura (y todos los 
componentes reutilizables en general) poseen una his- 
toria pasada, es posible recoger datos de costes para cada 
uno de ellos. En una situación ideal, los costes de adap- 
tación, integración y mantenimiento asociados a los com- 
ponentes de una biblioteca de reutilización se mantienen 
para cada caso de utilización. Entonces es posible ana- 
lizar estos datos para desarrollar una estimación de cos- 
tes para el próximo caso en que se utilicen. 

Como ejemplo, considérese una nueva aplicación, 
X, que requiere un 60 por 100de código nuevo, y la reu- 
tilización de tres puntos de estructura, PE,, PE, y PE.,. 
Cada'uno de estos componentes reutilizables ha sido 
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utilizado en un cierto número de aplicaciones adicio- 
nales, y los costes medios de adaptación, integración y 
mantenimiento están disponibles. 

¿Existe un cálculo rápido 


$ que permita estimar 

el beneficio de la reutilización 
de componentes en términos 
de coste? 


Para estimar el esfuerzo requerido para proporcionar 
la aplicación,X, es preciso efectuar el siguiente cálculo: 


esfuerzo global = E,,,,,,,, + Era AE E doptación +E 


integración 
donde 


Enuevo =8s el esfuerzo que el ingeniero requiere para cons- 
truirlos nuevos componentes de software (que se determina- 


rá empleando las técnicas descritas en el Capítulo 5); 


E; gu =88 el esfuerzo requerido para cualificar PE,, PE, y 

3> 

adaptaci ón =es el esfuerzo requerido para adaptar PE,, PE, 
y PEy; 

E ntegración =es el esfuerzo requerido para integrar PE,,PE, 
y PE,; 


El esfuerzo necesario para cualificar, adaptar e inte- 
grar PE,, PE, y PE, se determina calculando la media 
de datos históricos recogidos para la cualificación,adap- 
tación e integración de los componentes reutilizables 
en otras aplicaciones. 


27.6.3. Métricas de reutilización 


Se ha desarrollado toda una gama de métricas de soft- 
ware en un intento de medir los beneficios de la reuti- 


lización en un sistema basado en computadoras. Los 
beneficios asociados a la reutilización dentro de un sis- 
tema $ se pueden expresar como el siguiente cociente 


R, ()= [Cin reutilización” C con reutilización]/ Coin reutilización (271) 
donde 


ui... esel coste de desarrollar S sin reutilización, 
Cjy reutilización 
Y 
Cóo 
De lo que se deduce que R,(S) se puede expresar 
como un valor no dimensional que se encuentra en el 


intervalo 


y reutilización es el coste de desarrollar S con reutilización 


OSR(S) 1 (27.2) 


Devanbu y sus colaboradores [DEV95] sugieren que 
(DR, se verá afectado por el diseño del sistema; (2) 
dado que R, se ve afectado por el diseño, es importan- 
te hacer que R, forme parte de la estimación de alter- 
nativas de diseño; y (3) los beneficios asociados a la 
reutilización estarán íntimamente relacionados con los 
beneficios en términos de costes de cada uno de los com- 
ponentes reutilizables individuales. 

Se define una medida general de reutilización en los 
sistemas orientados a objetos, denominada apro *cha- 
miento de reutilización [BAN94] en la siguiente forma: 


R = OB A OB, construidos (27.3) 
donde 


OBJ 


reutilizados 
sistema; 


OB, cstridos 
sistema. 


aprovechado 


es el número de objetos reutilizados en el 


es el número de objetos construidos para el 


De lo que se deduce que a medida que aumenta 


Raptados también aumenta R,.. 


La ingeniería del software basada en componentes 
proporciona unos beneficios inherentes en lo tocante a 
calidad del software, productividad del desarrollador y 
coste general del sistema. Sin embargo, es preciso ven- 
cer muchas dificultades antes de que el modelo de pro- 
ceso ISBC se utilice ampliamente en la industria. 

Además de los componentes del software, un inge- 
niero del software puede adquirir toda una gama de 
elementos reutilizables. Entre estos se cuentan las 
representaciones técnicas del software (por ejemplo, 
especificación, modelos de arquitectura, diseños y 
códigos), documentos, datos de prueba e incluso tare- 
as relacionadas con los procesos (por ejemplo, técni- 
cas de inspección). 

El proceso ISBC acompaña a dos subprocesos con- 
currentes — ingenieríadel dominio y desarrollo basado 
en componentes —. El objetivo de la ingeniería del domi- 
nio es identificar, construir, catalogar y diseminar un 
conjunto de componentes de software en un determi- 
nado dominio de aplicación. A continuación, el desa- 
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rrollo basado en componentes cualifica, adapta e inte- 
gra estos componentes para su reutilización en un siste- 
ma nuevo. Además, el desarrollo basado en componentes 
diseña componentes nuevos que se basan en los requi- 
sitos personalizados de un sistema nuevo. 

Las técnicas de análisis y diseño de componentes 
reutilizables se basan en los mismos principios y con- 
ceptos que forman parte de las buenas prácticas de inge- 
niería del software. Los componentes reutilizables 
deberían de diseñarse en el seno de un entorno que esta- 
blezca unas estructuras de datos estándar, unos proto- 
colos de interfaz y unas arquitecturas de programa para 
todos los dominios de aplicación. 

La ingeniería del software basada en componentes 
hace uso de un modelo de intercambio de datos; herra- 
mientas, almacenamiento estructurado y un modelo 
objeto subyacente para construir aplicaciones. El mode- 
lo de objetos suele ajustarse a uno o más estándares de 
componentes (por ejemplo, OMG/CORBA) que defi- 
nen la forma en que una aplicación puede acceder a los 
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objetos reutilizables. Los esquemas de clasificación 
capacitan al desarrollador para hallar y recuperar com- 
ponentes reutilizables y se ajustan a un modelo que iden- 
tifica conceptos,contenidos y contextos. La clasificación 
enumerada, la clasificación de facetas, y la clasifica- 
ción de valores de atributos son representativas de 
muchos esquemas de clasificación de componentes. 


CAPITULO 2/ INGENIERIA DEL SUFIWARE BASADA EN COMPONENTES 


La economía de reutilización del software se abar- 
ca con una Única pregunta: ¿Es rentable construir 
menos y reutilizar más? En general, la respuesta es 
«sí», pero un planificador de proyectos de software 
debe considerar los costes no triviales asociados a la 
adaptación e integración de los componentes reutili- 
zables. 
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INGENIERÍA DEL SOFTWARE. UN ENFUQUE PKAUILICU 


27.1. Uno de los obstáculos principales de la reutilización con- 
sisteen hacer que los desarrolladores de software consideren la 
reutilización de componentes ya existentes, en lugar de volver 
a inventar otros nuevos. (¡Después de todo, es divertidocons- 
truir cosas!) Sugieratres o cuatro formas distintas en que una 
organización de software pueda proporcionar incentivos para 
que los ingenieros de software utilicen la reutilización. ¿Qué 
tecnologías deberían de estar implantadas para apoyarese esfuer- 
zo de reutilización? 


27.2. Aunque los componentes de software son los «elemen- 
tos»reutilizables más obvios, se pueden reutilizar muchas otras 
entidades producidas como parte de la ingeniería del software. 
Tenga en consideración los planes de proyecto y las estimacio- 
nes de costes. ¿Cómo se pueden reutilizar y cuál es el benefi- 
cio de hacerlo? 


27.3. Lleve acabo una pequeña investigación acercade la inge- 
niería de dominios, y detalle algo más el modelo de procesos 
esbozadoen la Figura 27.1. Identifique las tareas necesarias para 
el análisis de dominios y para el desarrollode arquitecturas de 
software. 


27.4. ¿En qué sentidoson iguales las funcionesde caracteriza- 
ción para los dominios de aplicaciones y los esquemas de cla- 
sificación de componentes? ¿En qué sentido son distintas? 


27.5. Desarrolle un conjunto de característicasdel dominio para 
sistemas de información que sean relevantes para el procesa- 
miento de datos de alumnos de una Universidad. 

27.6. Desarrolle un conjunto de característicasdel dominio que 
sean relevantes para el software de publicación y autoedición. 


CONSIDERAR la 


27.7. Desarrolle un modelo estructural sencillo para un domi- 
nio de aplicación que le asigne su instructor, o bien uno con el 
cual esté familiarizado. 


27.8. ¿Qué es un punto de estructura? 


27.9. Obtenga información de los estándares más recientes de 
CORBA, COM o de JavaBeans y prepare un trabajo de 3 a 5 
páginas que trate los puntos más destacables. Obtenga infor- 
mación de una herramienta de distribución de solicitudes de 
objetos e ilustreen que esa herramienta se ajusta al estándar. 


27.10. Desarrolle una clasificación enumerada para un dominio 
de aplicación que le asigne su instructoro para uno con el cual 
esté familiarizado. 


27.11. Desarrolle un esquema de clasificación por facetas para 
un dominio de aplicación que le asigne su instructor o bien para 
uno con el cual esté familiarizado. 


27.12. Investigue en la literatura para conseguirdatos recientes 
de calidad y productividad que apoyen la utilización. Presente 
esos datos al resto de la clase. 


27.13. Se estima que un sistema orientado a objetos requiere 
320 objetos para su finalización.Además, se estima que es posi- 
ble adquirir 190 objetos procedentes de un depósito ya exis- 
tente. ¿Cuál es el aprovechamiento de reutilización? Suponga 
que los objetos nuevos cuestan 260.000 pts., y que se necesitan 
156.000 pts. para adaptar un objeto y 104.000 pts. para inte- 
grarlo. ¿Cuál es el coste estimado del sistema? ¿Cuál es el valor 
de Rb? 


Durante los últimos años se han publicado libros sobre el 
desarrollo basado en componentes y la reutilización de com- 
ponentes. Allen, Frost y Yourdon (Component-Based Develop- 
mentfo r Enterprise Systems: Applying the Select Perspective, 
Cambridge University Press, 1998) abarca todo el proceso de 
ISBC mediante el uso de UML (Capítulos 21 y 22) basándose 
en el enfoque del modelado. Los libros de Lim (Managing Soft- 
ware Reuse: A Comprehensive Guide to Strategically Reengi- 
neering the Organization for Reusable Components, 
Prentice-Hall, 1998), Coulange (Software Reuse, Spriger Ver- 
lag, 1998), Reifer (PracticalSoftware Reuse, Wiley, 1997), 
Jacobson, Griss y Jonsson (Software Reuse: Architecture Pro- 
cess and Organizationfor Business Success, Addison-Wesley, 

1997) afronta muchos temas de ISBC. Fowler (Analysis Pat- 
terns: Reusable Object Models, Addison-Wesley, 1996)consi- 
dera la aplicación de patrones arquitectónicos dentro del proceso 
de ISBC y proporciona muchos ejemplos Útiles. Tracz (Con- 

fessions of a Used Program Salesman: Institutionalizing Soft- 
ware Reuse, Addison-Wesley, 1995) presenta un estudio algunas 
veces desenfadado y muy útil de los temas asociados con la cre- 
ación de una cultura de reutilización. 

Leach (Software Reuse: Methods, Models and Costs, 
McGraw-Hill, 1997) proporciona un análisis detallado de los 
estudios de costes asociados con la ISBC y con la reutilización. 
Poulin (Measuring Software Reuse: Principles, Practices, and 
Economic Models, Addison-Wesley, 1996) sugiere un número 
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de métodos cuantitativos para valorarlos beneficios de la reu- 
tilización del software. 

Durante los Últimos años se han publicado docenas de libros 
que describen los mismos estándares basados en componentes 
de la industria, pero también tienen en consideración muchos 
tópicos importantesde la ISBC. A continuación se muestra un 
muestreo del estudio de los tres estándares: 


CORBA 


Doss, G.M., CORBA Networking Java, Wordware 
Publishing, 1999. 

Hoque, R., CORBAfor Real Prograrnmers, Academic 
Press/Morgan Kaufmann, 1999, 

Siegel, J., CORBA3 Fundamentals and Programming, 
Wiley, 1999. 

Slama, D., J, Garbis y P. Russell, Enterprise CORBA, Pren- 
tice-Hall, 1999, 


COM 

Box, D.K., T. Ewald y C. Sells, Effective Ways to Impro- 
ve Your COM and MTS-Based Applications, Addison-Wes- 
ley, 1999, 

Kirtland, M., Designing Component-Based Applications, 
Microsoft Press, 1999. 


Muchas compañías aplican una combinación de estándares 
de componentes. Los libros de Geraghty et al. (COM-CORBA 
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Interoperubility, Prentice-Hall, 1999), Pritchard (COM and 
CORBA Side by Side: Architectures, Strutegies, und Imple- 
mentations, Addsion-Wesley, 1999) y Rosen et al. (Integrating 
CORBA und COM Applicutions, Wiley, 1999) tienen en consi- 
deración los temas asociados con la utilización de CORBA y 
COM como base para el desarrollobasado en componentes. 


JavaBeans 


Asbury, S., y S.R. Weiner, Developing Javu Enterprise 
Applications, Wiley, 1999. 
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ARE BASADA EN COMPONENTES 


Valesky, T.C., Enterprise JavaBeans: Developing Com- 
ponent-Based Distributed Applicutions, Addison-Wesley, 1999. 

Vogel, A., y M. Rangarao, Programming with Enterprise 
JavaBeans, JTS und OTS, Wiley, 1999. 


En Intemet está disponible una gran variedad de fuentes 
de información sobre la ingeniería del software basada en 
componentes. Una lista actualizada de referencias en la red 
que son relevantes para la ISBC se puede encontraren la direc- 
ción http://www.pressman5.com 
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CAPítiw% INGENIERIA DEL SOFTWARE 


28 


DEL COMERCIO ELECTRÓNICO 
CLIENTE / SERVIDOR 


finales de siglo, el desarrollo de una nueva generación de máquinas herramientas capa- 

ces de soportar fuertes tolerancias dieron poder a los ingenieros que diseñaban un pro- 

ceso nuevo de fabricación llamado producción en masa. Antes de la llegada de esta 
tecnología avanzada de máquinas herramientas, no se podían soportar fuertes tolerancias. Pero 
con esta tecnología se podían construir piezas intercambiables y fácilmente ensamblables — 
la piedra angular de la producción en masa—. 

Cuando se va a desarrollar un sistema basado en computadora, un ingeniero de software se 
ve restringido por las limitaciones de las tecnologías existentes y potenciado cuando las tec- 
nologías nuevas proporcionan capacidades que no estaban disponibles para las generaciones 
anteriores de ingenieros. La evolución de las arquitecturas distribuidas de computadora ha capa- 
citado a los ingenieros de sistemas y del software para desarrollar nuevos enfoques sobre cómo 
se estructura el trabajo y cómo se procesa la información dentro de una empresa. 

Las nuevas estructuras de las organizaciones y los nuevos enfoques de proceso de información 
(por ejemplo: tecnologías intranet e Intemet, sistemas de apoyo a las decisiones, software de gru- 
po, e imágenes) representan una salida radical de las primeras tecnologías basadas en minicom- 
putadoras o en mainframes. Las nuevas arquitecturasde computadorahan proporcionadola tecnología 
que ha hecho posible que las empresas vuelvan a diseñar sus procesos de negocio (Capítulo 30). 

En este capítulo, examinaremos una arquitectura dominante para el proceso de información 
—los sistemas cliente/servidor (C/S) dentro del contexto de los sistemas de comercio electró- 
nico—. Los sistemas cliente/servidor han evolucionado junto con los avances de la informáti- 
ca personal, en la ingeniería del software basada en componentes, con las nuevas tecnologías 
de almacenamiento, comunicación mejorada a través de redes, y tecnología de bases de datos 
mejoradas. El objetivo de este capítulo' es presentar una visión global y breve de los sistemas 
cliente/servidor con un énfasis especial en los temas de la ingeniería del software que deben de 
afrontarse cuando se analizan, diseñan, prueban y se da soporte a dichos sistemas C/S. 


VISTAZO RÁPIDO 


¿Qué es? Las arquitecturas cliente/servi- 


dor(C/8) dominan el horizonte de los sis- 
temas basados en computadora. Todo 
existe: desde redes de cajeros automá- 
ticos hasta Internet. y esto es debido a 
que el software que reside en una com- 
putadora - e Icliente— solicita servi- 
cios y/o datos de otracomputadora-el 
servidor—. La ingeniería del software 
cliente/servidor combina principios cor- 
vencionales, conceptos y métodos tra- 
tados anteriormente en este libro, con 
elementos de la ingeniería del softwa- 
re basada en componentes y orientada 


a objetos para crear sistemas C/S, 


¿Quién lo hace? Los ingenieros de soft- 


ware llevan acaboel análisis, diseño, 
implementación y prueba deestos sis- 
temas. 


¿Por qué esimportante? El impacto de 


los sistemas C/S en los negocios, el 
comercio. el gobierno y la ciencia es 


dominante. Puesto que los avances tec- 
nológicos(por ejemplo,desarrollo basa- 
doencomponentes,agentesdesolicitud 
de objetos, Java) cambian la forma de 
construir los sistemas C/S, en sucons- 
trucción se debe de aplicar un proceso 
de ingeniería del software sólido. 


¿Cuáles son los pasos? Los pasos que 


se siguen en la ingeniería de los siste- 
mas C/8 son similares a los que se apli- 
can durante la ingeniería del software 
basada en componentes y OO. El mode- 
lo de proceso es evolutivo, comenzan- 
do por la obtención de los requisitos. 

La funcionalidad seasigna alos subsis- 
temas decomponentesque seven a asig- 
n adespuésobienal clienteoal servidor 
de la arquitectura C/S, El diseño secen- 
tra enla integraciónde los componentes 
existentes y en la creación de compo- 
nentes nuevos. La implementacióny las 
pruebas luchan por ejercitarlafunciona- 


lidad del cliente y del servidordentro del 
contexto delosestándares deintegración 
detomponentes y de la arquitectura C/S. 


¿Cuél es el producto obtenido? Un 


sistema C/8 de alta calidad es el pro- 
ducto de la ingeniería del software C/S; 
También se producen otros productos 
de trabajo de software (tratados ante- 
riormente en este mismo libro). 


¿Cómo puedo estar seguro de que lo 


he hecho correctamente? Utili- 
zando las mismas prácticas SQA quese 
aplican en todos los procesos de inge- 
niería del software -—las revisiones téc- 
nicas formales evalúan los modelos de 
análisis y diseño—;las revisiones espe- 
cializadas consideran los temas aso- 
ciados a la integración de componentes 
y al software intermedio (middleware), 
y las pruebas se aplican para desvelar 
errores al nivel de componentes, sub- 
sistema, cliente y servidor. 


Y Parte de este capítulose ha adaptado a partir del material de cursos desarrollado por JohnPorter para el Client/Server Curri- 
culum ofrecidoen la Facultad de Ingeniería BEI de la Universidad de Fairfield. Se ha obtenido permiso para su utilización. 
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INGENIERÍA DEL SOFTWARE. Un oimoqgoa rro 


Los últimos diez años han sidotestigos de avances masi- 
vos en las áreas de computación. La primera es que el 
hardware se ha ido abaratandocada vez más, y a su vez 
se ha ido haciendo más potente: las computadoras de 
sobremesa hoy en día tienen la potencia que poseían los 
mainframes hace algunos años. La segunda área es la de 
las comunicaciones;avances tales como los sistemas de 
comunicación vía satélite y los sistemas de teléfonos digl- 
tales significa que ahoraes posible conectareconómica- 
mente y eficientementecon otros sistemas informáticos 
separados físicamente. Esto ha llevado al conceptode un 
sistema de computación distribuido. Dicho sistemacon- 
siste en un número de computadoras que están conecta- 
das y que llevan a cabo diferentes funciones. Existen 
muchas razones por las que tales sistemas se han hecho 
populares: 


Rendimiento. El rendimiento de muchos tipos de 
sistemas distribuidos se puede incrementar añadiendo 
simplemente más computadoras. Normalmente esta es 
una opción más sencilla y más barata que mejorar un 
procesador en un mainframe. Los sistemas típicos en 
donde se puede lograr este incrementoen el rendimiento 
son aquellos en donde las computadoras distribuidas 
llevan a cabo mucho proceso, y en donde la relación tra- 
bajo de comunicaciones y proceso es bajo. 


Compartición de recursos. Un sistema distribuido 
permite a sus usuarios acceder a grandes cantidades de 


datos que contienen las computadoras que componen el 
sistema. En lugar de tener que reproducir los datos en 
todas las computadoras se pueden distribuir por un 
pequeño número de computadoras. Un sistema distribuido 
también proporciona acceso a servicios especializados 
que quizás no se requieran muy frecuentemente, y que se 
puedan centralizaren una computadora del sistema. 


mputación C/S representa 
específico de proceso cooperativo 
onde la relación entre clientes 
relación de los componentes 
ware como del software. 


Tolerancia a fallos. Un sistema distribuido se puede 
diseñar de forma que tolere los fallos tanto del hardware 
como del software. Por ejemplo, se pueden utilizar varias 
computadoras que lleven a cabo la misma tarea en un 
sistema distribuido. Si una de las computadoras fun- 
cionaba mal, entonces una de sus hermanas puede 
hacerse cargo de su trabajo. Una base de datos de una 
computadora se puede reproducir en otras computado- 
ras de forma que si la computadora original tiene un mal 
funcionamiento, los usuarios que solicitan la base de 
datos son capaces de acceder a las bases de datos repro- 
ducidas. 


28.2.1. Clientes y servidores 


El propósito de esta sección es introducir tanto la idea 
de cliente como la de servidor. Estos son los bloques 
básicos de construcción de un sistema distribuido y, de 
esta manera, cuando se describa el diseño y el desarro- 
llo de dichos sistemas, será necesario tener conocimiento 
de sus funciones y de su capacidad. 

Un servidor es una computadora que lleva a cabo 
un servicio que normalmente requiere mucha poten- 
cia de procesamiento. Un cliente es una computadora 
que solicita los servicios que proporciona uno O más 
servidores y que también lleva a cabo algún tipo de 
procesamiento por sí mismo. Esta forma de organiza- 
ción de computadoras es totalmente diferente a los dos 
modelos que dominaron los años ochenta y principios 
de los noventa. 

El primer modelo se conoce como procesamientocen- 
tral (host). En este modelo de organización todo el pro- 
cesamiento que se necesitaba para una organización se 
llevaba a cabo por una computadora grande —normal- 
mente una mainframe— mientras que los usuarios 
emplean sencillasterminales informáticaso PCs de muy 
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poca potencia para comunicarse con el central. Los dos 
problemas más serios son la dificultad de mejorar y de 
copiar con interfaces IGU modernas. A medida que las 
aplicaciones van siendo más grandes, la carga de una main- 
frame común llega al punto en que también necesita mejo- 
rar y normalmentecon hardware de procesamientonuevo, 
memoria o almacenamientode archivos. Mejorar dichas 
computadorases más fácil que antes; sin embargo, pue- 
de resultar un proceso moderadamente difícil y caro €s 
ciertamente más caro y más difícil que añadir un servidor 
nuevo basado en PC a un conjuntode computadorascon- 
figuradas como clientes y servidores —. El segundo pro- 
blema es hacerse con interfaces IGU modernas. Para 
ordenar a una computadoraque visualice incluso una pan- 
talla relativamente primitiva relacionada, digamos, con 
unos cuantos botones y una barra de desplazamiento de 
la misma, conlleva tanto tráfico en las líneas de comuni- 
cación que un sistema podría colapsarse fácilmente con 
los datos que se utilizan para configurar y manterer una 
serie de interfaces basadas en IGUs. 

El segundo modelo de computación es en donde hay 
un grupo de computadoras actuando como servidores, 
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pero poseen poco procesamiento que llevar a cabo. Nor- 
malmente estos terminales poco inteligentes actuarían 
como servidores de archivos o servidores de impresión 
para un número de PCs potentes o minicomputadoras 
que llevarían a cabo el procesamiento y estarían conec- 
tados a una red de área local. Las computadoras clien- 
te solicitarían servicios a gran escala, como es obtener 
un archivo, llevando a cabo entonces el procesamiento 
de dicho archivo. De nuevo, esto conduce a problemas 
con el tráfico en donde, por ejemplo, la transmisión de 
archivos grandes a un número de clientes que requie- 
ren simultáneamente estos archivos hace que el tiempo 
de respuesta de la red vaya tan lento como una tortuga. 


La computacióncliente/servidor es un intento de equi- 
librar el proceso de una red hasta que se comparta la 
potencia de procesamiento entre computadoras que lle- 
van a cabo servicios especializados tales como acceder 
a bases de datos (servidores), y aquellos que llevan a cabo 
tareas tales como la visualización IGU que es más ade- 
cuado para el punto final dentro de la red. Por ejemplo, 
permite que las computadoras se ajusten a tareas espe- 
cializadas tales como el procesamientode bases de datos 
en donde se utilizan hardware y software de propósito 
especial para proporcionar un procesamiento rápido de 
la base de datos comparado con el hardware que se 
encuentra en las mainframes que tienen que enfrentarse 
con una gran gama de aplicaciones. 


¿Qué es la informática 
cliente /servidor? 


28.2.2, Categorías de servidores 


Ya se ha desarrollado una gran variedad de servidores. 
La siguiente lista ampliada se ha extraído de [ORF99]: 


Servidores de archivos. Un servidor de archivos pro- 
porciona archivos para clientes. Estos servidores se utili- 
zan todavía en algunas aplicaciones donde los clientes 
requieren un procesamiento complicado fuera del rango 
normal de procesamientoque se puede encontraren bases 
de datos comerciales. Por ejemplo, una aplicación que 
requiera el almacenamiento y acceso a dibujos técnicos, 
digamos que para una empresa de fabricación, utilizaría 
un servidor de archivos para almacenar y proporcionar 
los dibujos a los clientes. Tales clientes, por ejemplo, serían 
utilizados por ingenieros quienes llevarían a cabo opera- 
ciones con dibujos, operaciones que serían demasiado 
caras de soportar, utilizando una computadora central 
potente. Si los archivos solicitados no fueran demasiado 
grandes y no estuvieran compartidos por un número tan 
grande de usuarios, un servidorde archivos seríauna forma 
excelente de almacenar y procesar archivos. 


Servidores de bases de datos. Los servidores de 
bases de datos son computadoras que almacenan gran- 
des colecciones de datos estructurados. Por ejemplo, un 
banco utilizaría un servidorde bases de datos para alma- 
cenar registros de clientes que contienen datos del nom- 
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bre de cuenta, nombre del titular de la cuenta, saldo 
actual de la cuenta y límite de descubierto de la cuenta. 
Una de las característicasde las bases de datos que inva- 
lidan la utilización de los servidores de archivos es que 
los archivos que se crean son enormes y ralentizan el 
tráfico si se transfirieran en bloque al cliente. Afortu- 
nadamente, para la gran mayoría de aplicaciones no se 
requiere dicha transferencia; por ejemplo en una apli- 
cación bancaria las consultas típicas que se realizarían 
en una base de datos bancaria serían las siguientes: 
Encontrar las cuentas de los clientes que tienen un 
descubierto mayor de 2.000 pts. 

Encontrar el saldo de todas las cuentas del titular 
John Smith. 

Encontrartodas las órdenes regulares del cliente Jean 
Smith. 

Encontrar el total de las transacciones que se reali- 
zaron ayer en la sucursal de Manchester Picadilly. 


Actualmente una base de datos bancaria típica ten- 
drá millones de registros, sin embargo, las consultas 
anteriores conllevarían transferir datos a un cliente que 
sería solamente una fracción muy pequeña del tamaño. 

En un entorno de bases de datos cliente/servidor los 
clientes envían las consultas a la base de datos, nor- 
malmente utilizando alguna IGU. Estas consultas se 
envían al servidor en un lenguaje llamado SQL (Len- 
guaje de Consultas Estructurado). El servidor de bases 
de datos lee el código SQL, lo interpreta y, a continua- 
ción, lo visualiza en algún objeto HCI tal como una caja 
de texto. El punto clave aquíes que el servidor de bases 
de datos lleva a cabo todo el procesamiento, donde el 
cliente lleva a cabo los procesos de extraer una consul- 
ta de algún objeto de entrada, tal como un campo de tex- 
to, enviar la consulta y visualizar la respuesta del 
servidor de la base de datos en algún objeto de salida, 
tal como un cuadro de desplazamiento. 


Servidores de software de grupo. Software de 
grupoes el término que se utiliza para describir el soft- 
ware que organiza el trabajo de un grupo de trabajado- 
res. Un sistema de software de grupo normalmente 
ofrece las siguientes funciones: 


Gestionar la agenda de los individuos de un equipo 
de trabajo. 


Gestionar las reuniones para un equipo, por ejem- 
plo, asegurar que todos los miembros de un equipo 
que tienen que asistir a una reunión estén libres 
cuando se vaya a celebrar. 


Gestionar el flujo de trabajo, donde las tareas se dis- 
tribuyen a los miembros del equipo y el sistema de 
software de grupo proporciona información sobre la 
finalización de la tarea y envía un recordatorioal per- 
sonal que lleva a cabo las tareas. 


Gestionar el correo electrónico, por ejemplo, organi- 
zar el envío de un correo específico a los miembros 
de un equipo una vez terminada una tarea específica. 
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Un servidor de software de grupo guarda los datos 
que dan soporte a estas tareas, por ejemplo, almacena 
las listas de correos electrónicos y permite que los usua- 
rios del sistema de software de grupo se comuniquen 
con él, notificándoles, por ejemplo, que se terminado 
una tarea o proporcionándoles una fecha de reunión en 
la que ciertos empleados puedan acudir. 


3 ¿Qué es un servidor Web? 


Servidores Web. Los documentos Web se almace- 
nan como páginas en una computadora conocida como 
servidor Web. Cuando se utiliza un navegador (brow- 
ser) para ver las páginas Web normalmente pincha sobre 

«enlace en un documento Web existente. Esto dará 
como resultado un mensaje que se enviará al servidor 
Web que contiene la página. Este servidor responderá 
entonces enviando una página a su computadora, donde 
el navegador pueda visualizarlo. De esta manera los ser- 
vidores Web actúan como una forma de servidor de 
archivos, administrando archivos relativamente peque- 
ños a usuarios, quienes entonces utilizan un navegador 
para examinar estas páginas. Para comunicarse con un 
navegador Web, un cliente que utiliza un navegador está 
haciendo uso a su vez de un protocolo conocido como 
HTTP. 


Servidores de correo. Un servidor de correo ges- 
tiona el envío y recepción de correo de un grupo de usua- 
rios. Para este servicio normalmente se utiliza un PC de 
rango medio. Existen varios protocolos para el correo 
electrónico. Un servidor de correo estará especializado 
en utilizar solo uno de ellos. 


Servidores de objetos. Uno de los desarrollos más 
excitantesen la informática distribuida durante los últi- 
mos cinco años ha sido el avance realizado, tanto por 
parte de los desarrolladores, como por parte de los inves- 
tigadores, para proporcionar objetos distribuidos. Estos 
son objetos que se pueden almacenar en una computa- 
dora, normalmente un servidor, con clientes capaces de 
activar la funcionalidad del objeto enviando mensajes 
al objeto, los cuales se corresponden con métodos defi- 
nidos por la clase de objeto. Esta tecnología liberará 
finalmente a los programadores de la programación de 
bajo nivel basada en protocolos requerida para acceder 
a otras computadoras de una red. En efecto, esto per- 
mite que el programador trate a los objetos a 'distancia 
como si estuvieran en su computadora local. Un servi- 
dor que contiene objetos que pueden accederse a dis- 
tancia se conoce como servidor de objetos. 


Servidores de impresión. Los servidores de impre- 
sión dan servicio a las solicitudes de un cliente remoto. 
Estos servidorestienden a basarse en PCs bastante bara- 
tos, y llevan a cabo las funciones limitadas de poner en 
cola de espera las peticiones de impresión, ordenar a la 
impresora que lleve a cabo el proceso de impresión e 
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informar a las computadoras cliente que ya ha finali- 
zado una petición de impresión en particular. 


Servidores de aplicaciones. Un servidor de aplica- 
ciones se dedica a una aplicación única. Tales servidores 
suelen escribirse utilizando un lenguaje tal como Java o 
C++, Un ejemplo típico del servidor que se utiliza en el 
dibujo de un fabricante de aviones que gestionabalas ver- 
siones diferentes de dibujos producidos por el personal 
técnico iría dirigido a algún proceso de fabricación. 


28.2.3. Software intermedio (middleware) 


Hasta el momento probablemente ya tenga la impresión 
de que la comunicación entre cliente y servidores direc- 
ta. Desgraciadamente, esto no es verdad: normalmente 
existe por lo menos una capa de software entre ellos. 
Esta capa se llama software intermedio (middleware). 
Como ejemplo de software intermedio consideremos la 
Figura 28.1. Ésta muestra la comunicación entre un 
cliente ejecutando un navegador como Internet Explo- 
rer y un servidor Web. 


| Elsoftware 
intermedio 
determina 
El navegador dónde está 
solicita la página 
una página Web y la solicita 
al servidor 
== 
Navegador Servidor 
Web 
La página Web La página 
es devuelta es enviada 
al navegador al software 
intermedio 
por el servidc 


FIGURA 28.1. Software intermedio y servidor Web. 


Aquí el software intermedio que se encuentra entre 
el servidor Web y el cliente que ejecuta el navegador 
Web intercepta las peticiones que proceden del nave- 
gador. Si se hace una petición para una página Web 
entonces determina la localización del documento 
Web y envía una petición para esa página. El servidor 
responde a la petición y devuelve la página al software 
intermedio, quien la dirige al navegador que la visuali- 
zará en la pantalla del monitor que utiliza el cliente. 
Existen dos categorías de software intermedio: el soft- 
ware intermedio general y el software intermedio de 
servicios. El primero es el que está asociado a los ser- 
vicios generales que requieren todos los clientes y ser- 
vidores. El software típico que se utiliza como tal es: 


+. El software para llevar a cabo comunicaciones utili- 
zando el protocolo TCP/IP y otros protocolos de red. 
El software del sistema operativo que, por ejemplo, 


mantiene un almacenamiento distribuido de archi- 
vos. Este es una colección de archivos que se espar- 
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cen por un sistema distribuido. El propósito de esta 
parte del sistema operativo es asegurar que los usua- 
rios pueden acceder a estos archivos, de forma que 
no necesiten conocer la localización de los archivos. 


e, 

da 

E software intermedio es el centro de un sistema 
diente /servidor. 


El software de autentificación, el cual comprueba 
que un usuario que desee utilizar un sistema distri- 
buido pueda en efecto hacerlo. 

El software intermedioorientado a mensajes que ges- 
tiona el envío de mensajes desde clientes'a servido- 
res y viceversa. 


Clientes 


Clientes 
Instalaciones 
Cola de de servidor 


Cola de O 
entrada Servidor eS entrada O 


Cola de 
salida 


(a) (b) 


FIGURA 28.2. Configuraciones Mom. 


El software intermedio de servicios es el software 
asociado a un servicio en particular. Entre los ejemplos 
típicos de este tipo de software se incluyen: 


+ Un software que permite a bases de datos diferentes 
conectarse a una red clienteiservidor. Probablemente 
el mejor ejemplo de este tipo de software sea la 
ODBC (Conectividad abierta de bases de datos) 
(Open Database Connectivity)) producida por Micro- 
soft. Esta permite que existan felizmente en una red 
la vasta mayoría de sistemas de gestión de bases de 
datos. 

Un software específico de objetos distribuidos tal 
como el que está asociado a CORBA. CORBA es 
una tecnología de objetos distribuida que permite a 
objetos escritos en una gran variedad de lenguajes 
que coexistan felizmente en una red de tal forma que 
cualquier objeto pueda enviar mensajes a otro objeto. 
El software intermedio de CORBA tiene que ver con 
funciones tales como configurarobjetos distribuidos, 
comunicación y seguridad entre objetos. 

Un software intermedio de Web asociado al proto- 
colo HTTP. 

Un software intermedio de software de grupo que 
administra los archivos que describen a los equipos 
de trabajo y sus interacciones. 
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+. Un software intermedio asociado a productos de 
seguridad específicos. Un buen ejemplo es el soft- 
ware intermedio asociado a lo que se conoce como 
conexiones (sockets) seguras. Estas son conexiones 
que se pueden utilizar para enviar datos seguros en 
una red de tal forma que hace imposible que intru- 
sos escuchen a escondidas los datos. Este tecnología 
se describe en la Sección 28.8. 


28.2,4. Un ejemplo de software intermedio 


El software intermedio orientado a mensajes es el soft- 
ware intermedio que administrael flujo de mensajes hacia 
y desde un cliente. Esta sección estudia detalladamente 
este software con el fin de proporcionar un ejemplo de 
un tipo específicode software intermedio. Para referirse 
al software intermedio orientado a mensajes a menudo 
seutiliza la sigla MOM. Es el que gestiona de forma efi- 
caz las colas que contienen mensajes que proceden y que 
se envían desde servidores. La Figura 28.2 muestra un 
número de configuraciones.La Figura 28.2 (a) muestra 
un número de clientes que acceden a dos colas, una cola 
de entrada a la que envían los mensajes y una cola de sali- 
da desde la que toman los mensajes y un único servidor 
que lee y escribe los mensajes. Un mensaje de entrada 
típico podría ser el que ordena al servidor que encuentre 
algunos datos en una base de datos y un mensaje de sali- 
da podría ser los datos que se han extraído de la base de 
datos. La Figura 28.2 (b) muestra múltiples clientes y un 
número de instanciaciones del programa servidor que tra- 
bajan concurrentementeen las mismas colas. 

Hay que establecer una serie de puntualizaciones a 
cerca de un software MOM: 


+. No senecesita estableceruna conexión especializada 
mientras que el cliente y el servidor interactúan. 

+. El modelo de interacción entre clientes y servidores 
es, en efecto, muy simple: los clientes y servidores 
interactúan mediante colas. Todo lo que necesita 
hacer el programador del cliente y del servidor es 
enviarun mensaje a la cola. El software MOM a nivel 
de programador es muy simple. 

+. Utilizando el software MOM la comunicación es 
asíncrona, hasta el punto en que la mitad de la pareja 
cliente/servidor puede que no esté comunicándose 
con la otra parte. Por ejemplo, el cliente puede que 
no esté ejecutándose: puede detenerse para su man- 
tenimiento y que el servidor siga mandando mensa- 
jes a colas MOM. Puede que el cliente haya cerrado 
con algunos mensajes a la espera de que los procese 
el servidor. El servidor puede colocar estos mensa- 
jes en la cola de manera que la próxima vez que el 
cliente se conecte pueda leer los mensajes. Este esce- 
nario es el ideal para la informática móvil. 


“3 
LAVE 


Cuando se utiliza el software MOMIla comunicación es asíncrona. 
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El propósito de esta sección es explorar la idea de una 
arquitectura estratificada para una aplicación cliente/ser- 
vidor y se limita a describir las arquitecturas populares 
de dos y de tres capas. Una arquitectura de dos capas de 
una aplicación cliente/servidor consiste en una capa de 
lógica y presentación, y otra capa de bases de datos. La 
primera tiene que ver con presentar al usuario conjuntos 
de objetos visuales y llevar a cabo el procesamiento que 
requieren los datos producidos por el usuario y los devuel- 
tos por el servidor. Por ejemplo, esta capa contendría el 
código que monitoriza las acciones de pulsar botones, el 
envío de datos al servidor, y cualquier cálculolocal nece- 
sario para la aplicación. Estos datos se pueden almace- 
nar en una base de datos convencional, en un archivo 
simple O pueden ser incluso los datos que están en la 
memoria. Esta capa reside en el servidor. 

Normalmente las arquitecturas de dos capas se uti- 
lizan cuando se requiere mucho procesamientode datos. 
La arquitectura del servidor Web de navegador es un 
buen ejemplo de una arquitecturade dos capas. El nave- 
gador del cliente reside en la capa de lógica y presen- 
tación mientras que los datos del servidor Web—-las 
páginas Web— residen en las capa de la base de datos. 
Otro ejemplo de aplicación en donde se emplearía nor- 
malmente una arquitectura de dos capas es una aplica- 
ción simple de entrada de datos, donde las funciones 
principales que ejercitan los usuarios es introducir los 
datos de formas muy diversas en una base de datos 
remota; por ejemplo, una aplicación de entrada de datos 
de un sistema bancario, donde las cuentas de usuarios 
nuevos se teclean en una base de datos central de cuen- 
tas. El cliente de esta aplicación residirá en la capa lógi- 
ca y de presentación mientras que la base de datos de 
cuentas residiría en la capa de base de datos. 

Las dos aplicaciones descritas anteriormente mues- 
tran la característica principal que distingue a las apli- 
caciones de capas de otras aplicaciones que emplean 
más capas por el hecho de que la cantidad de procesa- 
miento necesario es muy pequeña. Por ejemplo, en la 
aplicación de validación de datos, el Único procesa- 
miento requerido del lado del cliente sería la validación 
de datos que se llevaría a cabo sin recurrir a la base de 
datos de las cuentas. Un ejemplo sería comprobar que 
el nombre de un cliente no contiene ningún dígito. El 
resto de la validación se haría en la capa de la base de 
datos y conllevaría comprobar la base de datos para ase- 
gurar que no se añadieron registros duplicados de clien- 
tes a la base de datos. Reece [REE97] ha documentado 
los criterios que se deberían utilizar cuando considera- 
mos adoptar una arquitectura cliente servidor de dos 
capas. Estos son los criterios: 


¿Utiliza la aplicación una única base de datos? 


+ ¿Se localiza el procesador de base de datos en una 
sola CPU? 


496 


¿Es relativamente estática la base de datos en lo que 
se refiere a predecir un crecimiento pequeño de 
tamaño y estructura? 

¿Es estática la base del usuario? 


¿Existen requisitos fijos Oo no hay muchas posibili- 
dades de cambio durante la vida del sistema? 
¿Necesitará el sistema un mantenimiento mínimo? 


Aunque algunas de estas cuestiones van enlazadas 
(los cambios en los requisitos dan lugar a las tareas de 
mantenimiento), se trata de un cantidad bien amplia de 
preguntas que deberían de tenerse en cuenta antes de 
adoptar una arquitectura de dos capas. 


CLAVE 


Cuando una aplicación implica un procesamiento 
considerableel enfoque de dos copas cada vez 
es más difícil de implementar. 


Cuando una aplicación implica un procesamientocon- 
siderable, entonces comienzan a surgir problemas con 
la arquitectura de dos capas, particularmente aquellas 
aplicaciones que experimentan cambios de funcionali- 
dad a medida que se van utilizando. También, una arqui- 
tectura de dos capas, donde no hay muchas partes de 
código de procesamiento unidas a acciones tales como 
pulsación de botones o introducción de texto en un cam- 
po de texto, está altamente orientada a sucesos específ1- 
cos y no alos datos subyacentes de una aplicación, y de 
aquí que la reutilización sea algo complicado. 


Capa Capa del servidor Capa de bases 
de presentación de la aplicación de datos 
Objetos 
Ej negocios 
Alguna base 
de datos 


má 


FIGURA 28.3.Una arquitectura de tres capas. 


La Figura 28.3 muestra una arquitectura de tres capas. 
Se compone de una capa de presentación, una capa de 
procesamiento (o capa de servidor de solicitudes) y una 
capa de base de datos. La capa de presentación es la res- 
ponsable de la presentación visual de la aplicación, la 
capa de la base de datos contiene los datos de la apli- 


www.elsolucionario.net 


CAPITULO 28 INGENIEKIA DEL SOFWARE DEL CUMERCIO ELECTRONICO CLIENTE/SERVIDOR 


cación y la capa de procesamiento es la responsable del 
procesamiento que tiene lugar en la aplicación. Por ejem- 
plo, en una aplicación bancaria el código de la capa de 
presentación se relacionaría simplemente con la moni- 
torización de sucesos y con el envío de datos a la capa 
de procesamiento. Esta capa intermedia contendría los 
objetos que se correspondencon las entidades de la apli- 
cación; por ejemplo, en una aplicación bancaria los obje- 
tos típicos serían los bancos, el cliente, las cuentas y las 
transacciones. 

La capa final sería la capa de la base de datos. Ésta 
estaría compuesta de los archivos que contienen los 
datos de la aplicación. La capa intermedia es la que 
conlleva capacidad de mantenimiento y de reutiliza- 
ción. Contendrá objetos definidos por clases reutili- 
zables que se pueden utilizar una y otra vez en otras 
aplicaciones. Estos objetos se suelen llamar objetos de 
negocios y son los que contienen la gama normal de 
constructores, métodos para establecer y obtener varia- 
bles, métodos que llevan a cabo cálculos y métodos, 
normalmente privados, en comunicación con la capa 
de la base de datos. La capa de presentación enviará 
mensajes a los objetos de esta capa intermedia, la cual 
o bien responderá entonces directamente o mantendrá 
un diálogo con la capa de la base de datos, la cual pro- 
porcionará los datos que se mandarían como respues- 
ta a la capa de presentación. 

El lugar donde va a residir la capa intermedia depen- 
de de la decisión sobre el diseño. Podría residir en el 
servidor, que contiene la capa de base de datos; por otro 
lado, podría residir en un servidor separado. La deci- 
sión sobre dónde colocar esta capa dependerá de las 
decisiones sobre diseño que se apliquen, dependiendo 
de factores tales como la cantidad de carga que tiene un 
servidoren particular y la distancia a la que se encuen- 


Tipo 
(8 bits) 


Código 
(8 bits) 


Parámetros j 
Datos Ñ 


FIGURA 28.4. El formato del protocolo ICMP. 


Suma de 
verificación 


tra el servidor de los clientes. La localización de esta 
capano le resta valor a las ventajas que proporciona una 
arquitectura de tres capas: 


+ En primer lugar, la arquitectura de tres capas permite 
aislar a la tecnología que implementa la base de datos, 
de forma que sea fácil cambiar esta tecnología. Por 
ejemplo, una aplicación podría utilizar en primer 
lugar la tecnología relacional para la capa de base de 
datos; si una base de datos basada en objetos fun- 
ciona tan eficientemente como la tecnología rela- 
cional que se pudiera entonces integrar fácilmente, 
todo lo que se necesitaría cambiar serían los méto- 
dos para comunicarse con la base de datos. 


« Utiliza mucho código lejos del cliente. Los clien- 
tes que contienen mucho código se conocen como 
clientes pesados (gruesos). En un entorno en donde 
se suele necesitar algún cambio, estos clientes 
pesados pueden convertirse en una pesadilla de 
mantenimiento. Cada vez que se requiere un cam- 
bio la organización tiene que asegurarse de que se 
ha descargado el código correcto a cada cliente. 
Con una capa intermedia una gran parte del código 
de una aplicación cliente/servidor reside en un lugar 
(o en un número reducido pequeño de lugares si se 
utilizan servidores de copias de seguridad) y los 
cambios de mantenimiento ocurren de forma cen- 
tralizada. 


+ La idea de las tres capas encaja con las prácticas 
orientadas a objetos de hoy en día: todo el procesa- 
miento tiene lugar por medio de los mensajes que se 
envían a los objetos y no mediante trozos de código 
asociados a cada objeto en la capa de presentación 
que se está ejecutando. 


EP VE 


Existe una diferencia enire el software intermedio 
(middleware) y la capa del servidor de la aplicación. 


Lo que merece la pena destacar, llegado este pun- 
to, es que existe una diferencia entre la capa inter- 
media del servidor de la aplicación y el software 
intermedio (middleware). Mientras que el primero des- 
cribe el software de la aplicación que media entre el 
cliente y el servidor, el segundo se reserva para el soft- 
ware de sistemas. 


En este capítulo hasta ahora se ha utilizado el térmi- 
no protocolo sin proporcionar realmente mucho deta- 


lle. El propósito de esta sección es proporcionar este 
detalle. 


28.41. El concepto 


Con objeto de describir lo que es exactamente un pro- 


tocolo, utilizaré un pequeño ejemplo: el de un cliente 
que proporciona servicios bancarios para casa, permi- 
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tiendo, por ejemplo, que un cliente consulte una cuen- 
ta cuyos datos residen en el servidor. Supongamos que 
el cliente se comunica con el servidor que utiliza una 
serie de mensajes que distinguen las funciones requeri- 
das por el cliente, y que también se comunica con otros 
datos requeridos por el servidor. 

Por ejemplo, el cliente puede ejercer la función de 
consultar un saldo de cuenta tecleando un número de 
cuenta en un cuadro de texto y pulsando el botón del 
ratón el cual enviará el mensaje al servidor. Este men- 
saje podría ser de la forma 


CS*<Número de cuenta, 


donde CS (Consulta del Saldo) especifica que el usua- 
rio ha consultado una cuenta para obtener el saldo con 
el número de cuenta que identifica la cuenta. El servi- 
dor entonces recibirá este mensaje y devolverá el sal- 
do; el mensaje que el servidor envía podría tener el 
formato 


Ss*<Cantidad del Saldo> 


El cliente interpretara este mensaje y visualizara el 
saldo en algún elemento de salida. 

Si el cliente quisiera consultar los números de cuen- 
tas de todas las cuentas con las que él o ella está aso- 
ciado, el mensaje entonces podría ser de la forma 


* 


cc 


donde CC (Consulta de Cuenta) solicita las cuentas, y 
en cuya función ya no se requieren más datos. El ser- 
vidor podría responder con un mensaje que comenza- 
ra con (Información de Cuenta) y que estuviera 
formado por números terminados con asteriscos. Por 
ejemplo, 


1C*2238997*88765 "882234 


los mensajes que he descrito forman un protocolo sen- 
cillo que comunica funcionalidad y datos entre dos enti- 
dades (un cliente y un servidor) en la red. 


¿Qué es un protocolo? 


Un punto importante acerca de los protocolos es que 
siempre que se utiliza un mecanismo para la comuni- 
cación en una red existe un protocolo. Por ejemplo, los 
objetos distribuidos son objetos que se encuentran en 
localizaciones remotas en una red, y es mediante la uti- 
lización de un protocolo la manera en que se envían los 
mensajes, aunque la programación de estos objetos esté 
a un nivel superior por debajo de la programación y 
oculta al programador. 

El protocolo que he descrito se asemeja a un jugue- 
te y también a un protocolo de aplicaciones. Merece 
la pena entrar en el estudio de algunos protocolos más 
reales que estén asociados a los servicios de nivel de 
sistema. 
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28.4,2. IP e ICMP 


IP, el protocolo que ejecuta Internet es un protocolo muy 
complicado, y una descripción completa estaría fuera 
del ámbito de este libro, ya que la descripción de este 
protocolo necesitaría un libro entero que le hiciera jus- 
ticia. Debido a esto me centraré en una parte pequeña 
del protocolo, aunque importante, conocida como ICMP 
(InternetControl Message Protocol). Protocolo de men- 
sajes de control de Internet que se utiliza para monito- 
rizar los errores y problemas de la red que utiliza IP. En 
la Figura 28.4 se muestra el formato de los mensajes 
que forman parte del protocolo. 

El campo Tipo especifica el tipo de error que ha ocu- 
rrido. Por ejemplo, este campo indicaría que el desti- 
no de un mensaje era inalcanzable. El campo Código 
contiene la información secundaria que se utiliza para 
proporcionar una interpretación más detallada del cam- 
po Tipo. El campo de Suma de verificación es utiliza- 
do por el software para comprobar que la transmisión 
del mensaje ICMP se ha llevado a cabo correctamen- 
te. Los dos campos restantes contienen los datos que 
permitirán al software de comprobación localizar el 
problema originado. 

ICPM es utilizado por IP para llevar a cabo el pro- 
cesamiento básico de errores y también para incremen- 
tar la eficacia de la red. Por ejemplo, se podría utilizar 
para llevar a cabo el cambio de dirección del mensaje 
si una computadora, que se encontrara en el camino ini- 
cial del mensaje, descubriera una ruta mejor. 


28.4.3. POP3 


POP3 ( Post Office Protocol version 3) (Protocolo de 
Oficina de Correos versión 3) se utiliza para el envío y 
la recepción de correo electrónico. Es un protocolo sen- 
cillo y es ampliamente utilizado. En esta sección reali- 
zaré un estudio de algunas de sus características. 


Cons 


POP3 es un protocolo robusto y muy sencillo. 
Utilícelo todo lo posible más que otros protocolos 


Existen varios protocolos de correo, entre los que se 
incluyen SMTP, IMAP y diferentes versiones de POP. 
Probablemente el más complicado de estos sea IMAP, 
el cual incluye funciones secundarias y un conjunto de 
mensajes más rico que POP. 

El propósito de POP es posibilitar a los usuarios 
acceder al correo remoto y consta de una serie de 
comandos que permiten a los programas de usuario 
interactuar con un servidor de correo POP. El están- 
dar POP3 describe un grupo de mensajes posibles que 
pueden enviarse al servidor de correo POP3 y el for- 
mato de los mensajes es devuelto por el servidor. La 


Tabla 28.1 muestra un subconjunto pequeño del pro- 
tocolo POP3, 
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Mensaje Significado 

USER Informa al servidor sobre un usua- 
rio enparticular que está intentan- 
do enviar un correo 

PASS Proporciona una contraseña para 
un usuario en particular 

STAT Pregunta al servidor cuántos men- 
sajes hay esperandopara ser leídos 

DELE Borra un mensaje 

RETR Recupera un mensaje 


TABLA 28.1. Un subconjunto del POP3. 


284.4. El protocolo HTTP 


Este es uno de los protocolos más importantes que se 
utilizan dentro de Internet; es el protocolo que rige 
la comunicación entre un cliente que utiliza un nave- 
gador Web tal como Internet Explorer y un servidor 
Web. 

La función principal de un servidor Web es poner a 
disposición de clientes páginas Web. Estos clientes uti- 
lizarán un navegador que les conectará al puerto 80 en 
el servidor Web; este es el puerto estándar que se utili- 
za para tales servidores. El navegador que está utili- 
zando el cliente .enviará mensajes definidos por el 


protocolo HTTP y serán interpretados por el servidor 
que llevará a cabo operaciones tales como devolver una 
página Web o procesar algún formulario que esté inser- 
tado dentro de una página. 

A continuación, se muestra un ejemplo que ilustra lo 
descrito anteriormente 


GET/index.html HTTP/ 1.1 


Este es el mensaje que envía un navegador cuando 
quiere visualizar una página en particular. Este mensa- 
je se puede haber generado de diferentes maneras. Por 
ejemplo, el usuario puede haber pinchado con el ratón 
en un determinado enlace en un documento Web que 
señala a la página solicitada. La línea anterior contiene 
la palabra reservada GET, la cual especificaba que se 
iba a devolver un archivo, y especificaba también el 
nombre del archivo que sigue al carácter '/' (index.html) 
y la versión del protocolo que utiliza el navegador que 
va a enviar el mensaje. 

El servidor también utilizará el protocolo HTTP para 
enviar mensajes de vuelta al cliente. Por ejemplo, el 
mensaje 


HTTP/1.1 200 OK 


significa que el servidor, que está utilizando HTTP ver- 
sión 1.1, ha procesado con éxito la petición iniciada por 
el cliente. El código 200 en este caso es un ejemplo del 
código de estado que indica éxito. 


28.5.1, ¿Qué es el comercio electrónico? 


Para ilustrar la aparienciade un sistema distribuido exa- 
minaremos un ejemplo tomado de un área de aplicación 
conocida como comercio electrónico. En un sentido 
amplio, el término «comercio electrónico» (Ecommer- 
ce) se puede definir como la aplicación de la tecnología 
de sistemas distribuidos que apoya las operacionescomer- 
ciales. A continuación, se detallan algunos de dichos sis- 
temas: 


+ Sistemas para vender algunos artículos o servicios 
utilizando Internet, donde los clientes interactúan 
con el sistema que utiliza navegadores. Entre los 
sistemas típicos de comercio electrónico de esta 
categoría se incluyen los que venden libros, ropa 


y CDs. 


¿Qué es el comercio 
electrónico? 


+ Sistemas para simular alguna actividad comercial en 
tiempo real utilizando tecnología de red. Un buen 
ejemplo de este tipo de sistemas es una subasta en la 
red,Un sistema de subasta típico solicitaría artícu- 
los a los usuarios de Internet, ubicaría los datos en 
una página Web y entonces comenzaría la oferta para 


ese artículo. Normalmente la compañía de subastas 
especificaría un período de oferta para así darla por 
finalizada. 


. Sistemas que proporcionan algún servicio basado en 
red para usuarios. Probablemente los más conocidos 
son los que ofrecen cuentas de correo gratis, donde 
los ingresos de dicha empresa probablemente pro- 
cedan de la publicidad en las páginas Web que se uti- 
lizan para ese sitio Web. Estas son compañías que 
mediante un honorario monitorizan su sitio Web y le 
envían un mensaje, normalmente por correo elec- 
trónico O mediante un buscador si han detectado un 
problema, como el mal funcionamiento del servidor 
que se utiliza para el sitio Web. 


+ Sistemas que proporcionan servicios de asesora- 
miento. Los sistemas típicos de este tipo son los que 
procesan una descripción de artículos, como un CD, 
para los que establecerán el mejor precio, después 
de haber explorado un número de sistemas de venta 
en la red. 


+ Sistemas internos que el cliente no ve, pero que dan 
soporte a más actividades comerciales convenciona- 


les. Por ejemplo, un sistema que apoya el suministro 
de mercancías a un comerciante minorista de la calle. 
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+ Sistemas de publicidad. Muchos de los ingresos del 
comercio electrónico proceden de la publicidad en 
línea. Muchas páginas Web asociadas a las aplica- 
ciones de comercio electrónico contendrán peque- 
ños espacios publicitarios conocidos como banners. 
Estos anuncios se pueden «pinchar», conduciendo 
así al usuario del navegador a un sitio Web el cual 
normalmente vende algún producto o servicio. Los 
sistemas de publicidad son una forma particular de 
sistemas de comercio electrónico que llevan a cabo 
funciones tales como vender un banner (espacio 
publicitario), monitorizando el éxito de estos anun- 
cios y la administración del pago de los honorarios 
de publicidad. 


Estas forman un conjunto típico de aplicaciones 
que están bajo el «banner» del comercio electrónico. 
En la parte restante de esta sección observaremos una 
aplicación típica de comercio electrónico que admi- 
nistra la venta de un artículo. Esto es lo que piensa 
cualquier persona de una aplicación de comercio 
electrónico, aunque espero que después de leer este 
preámbulo este sistema se considerará sólo como un 
tipo de sistema. 


») 
j Cia 
El comercio electrónico no es solamente 
un comercio minorista de red. 


28.5.2. Un sistema típico de comercio electrónico 


Con objeto de entender la naturaleza de los sistemas 
cliente/servidor, merece la pena examinar un ejemplo 
de una de las áreas del comercio electrónico. Es un sis- 
tema para administrar las ventas de una gran librería 
que tenga una funcionalidad similar a la que exhiben 
grandes librerías como Blackwells o la filial británica 
de Amazon. Las funciones típicas que un sistema como 
éste proporciona son las siguientes: 


« Laprovisión de servicios de Catálogo. Cada libro 
que venda una compañía estará en catálogo y la 
página Web proporcionará la descripción de ese libro. 
La información típica que se proporciona sobre un 
libro es el nombre, autor, editorial y precio. 


»  Laprovisión de servicios de búsqueda. El usuario de 
dicho sistemanecesitará navegar por el catálogo para 
decidir si va a comprar un libro. Esta navegación se 
podría realizar de muchas maneras diferentes: desde 
navegar secuencialmente desde el primer libro que 
aparece, hasta navegar utilizando consultas de bús- 
queda tal como el título de un libro o su ISBN. 


. Laprovisión de servicios de pedidos. Cuando un 
cliente de un sitio de comercio electrónico quiere 
comprar un libro, el sistema le proporcionará algún 
servicio para poderlo hacer y, normalmente, mediante 
tarjetas de crédito. Generalmente cuando el cliente 
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realiza el pedido de un libro, a continuación se le 
solicitan los datos de la tarjeta de crédito. Algunos 
sistemas de pedidos suelen quedarse con los datos 
de las tarjetas de forma permanente de manera que 
no se requiere que el cliente proporcione los datos 
cada vez que haga un pedido. 


La provisión de servicios de seguimiento. Estos ser- 
vicios posibilitarán al cliente seguir con el proceso 
de una compra utilizando su navegador. Las páginas 
Web personalizadas para el cliente describirán el 
desarrollo de un pedido: si ya se ha enviado, si está 
esperando porque el libro no está en stock, y cuál es 
la fecha en la que se espera enviar el pedido. 


El procesamiento de revisiones. Un servicio ofrecido 
por los sitios de ventas de libros más sofisticados y 
es el que proporciona el medio por el que los clien- 
tes pueden escribir revisiones de los libros a com- 
prar. Estas revisiones se pueden comunicar al 
vendedor o bien por correo electrónico o por una 
página Web especializada. 


La provisión de un servicio de conferencia. Un ser- 
vicio de conferencia capacita a un grupo de clientes 
para interactuar entre ellos enviando mensajes a una 
conferencia, entendiendo por conferencia algo dedi- 
cado a un tema específico tal como, por ejemplo, la 
última novela de Robert Goddard o el estado de la 
ficción criminal. Tales servicios no proporcionan 
ingresos directamente a un vendedor de libros en red. 
Sin embargo, sí pueden proporcionar información 
Útil sobre las tendencias en las compras de libros de 
las que el personal de ventas de una librería pueden 
sacar provecho. 


La provisión de noticias o boletines para clientes. 
Un servicio popular que se encuentra en muchos 
sitios de comercio electrónico dedicados a la venta 
de un producto es el de proporcionar información 
por medio del correo electrónico. Para el sitio de ven- 
tas de libros que se está describiendo en esta sección 
se incluirían mensajes tal como textos de revisiones, 
ofertas especiales o mensajes relacionados con un 
pedido específico, tal como el hecho de haberse des- 
pachado. 


Control y administración del stock. Este es un con- 
junto de funciones que están ocultas para el usuario 
del sistema de ventas de libros pero que son vitales 
para el sistema. Estas funciones se asocian a las acti- 
vidades mundanas, tales como hacer pedidos de 
libros, hacer el seguimiento de los stocks y reorde- 
nar y proporcionar información de ventas al perso- 
nal responsable de los pedidos. 


Informes financieros. Estos son de nuevo un con- 
junto de funciones que están ocultas ante los ojos del 
usuario del sistema de ventas de libros pero que son 
vitales. Proporcionan la información para la gestión 
financiera de la compañía que ejecuta el sistema y 
proporciona la información de datos tales como las 
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ventas día a día, anuales y datos más complejos tales 
como la efectividad de ciertas estrategias de ventas 
respecto a las ventas de los libros que eran el tema 
de estas estrategias. 


Se puede decir que estas son un conjunto típico de 
funciones mostradas por el comercio electrónico dedi- 
cado a vender productos; en nuestro caso el produc- 
to son libros, aunque no hay ninguna razón para no 
haber elegido, por ejemplo, ropa, CDs, antigiijedades, 
etc., aunque las funciones del sistema variarían un 
poco; por ejemplo, en un sitio especializado en ven- 
der ropa no habría razón por la que implementar las 
funciones que están conectadas con las revisiones de 
productos. 

Antes de estudiar la arquitectura de dicho sistema 
merece la pena hacer hincapié en el desarrollo de tales 
sistemas. Durante el nivel de análisis hay poca diferen- 
cia entre el sistema de comercio electrónico y un siste- 
ma más convencional, tal como el que depende de los 
operadores telefónicos para anotar los pedidos y donde 
el catálogo se imprime y se envía a los clientes de la 
forma convencional. Ciertamente existirán funciones 
que no estarán dentro de tales sistemas convencionales, 
como por ejemplo los que tienen que ver con las revi- 
siones; sin embargo, la mayor parte de las funciones son 
muy similares, y es posible que se lleven a cabo de for- 
ma diferente; por ejemplo, el proceso de obtener los 
datos de las tarjetas de crédito sería llevado a cabo por 
un operador y no por una página Web. 


: CLA VE 


Enel nivelde análisis hay muy poca diferencia entre los 
sistemas de comercio electrónico y lOs convencionales. 


En la Figura 28.5 se muestra la arquitectura técnica 
de un sistema de libros típico. Los componentes de este 
sistema son: 

. Clientes Web. Estos ejecutarán un navegador que 
interactúa con el sistema y que principalmente lleva 
acabo funciones de navegar sobre catálogos y hacer 
pedidos. 

. Unservidor Web. Este servidor contendrá todas las 
páginas Web a las que el cliente irá accediendo y se 
comunicará con el resto del sistema para proporcio- 
nar información tal como la disponibilidad de un 
libro. Normalmente existirá más de un servidor Web 
disponible para enfrentarse con un fallo del hard- 
ware. Si el servidor Web estaba funcionando y se 
viene abajo, dicho suceso sería extremadamente seno 
y se correspondería con las puertas de una librería 
convencional cerrada a los clientes impidiendo su 
entrada. Debido a las cajas registradoras, los siste- 
mas de correo electrónico que tienden a ser muy crí- 
ticos para un negocio tendrán hardware reproducido, 
incluyendo reproducciones de servidores de Web. 
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FIGURA 28.5. La arquitectura. 


Un servidor de correo. Este servidor mantendrá lis- 
tas de correos de clientes que, por ejemplo, han indi- 
cado que desean estar puntualmente informados de 
las ofertas especiales y los libros nuevos que se están 
publicando. Este servidor se comunicará con el ser- 
vidor Web principal, ya que los clientes proporcio- 
narán sus direcciones de correo y los servicios que 
quieren, interactuando con las páginas Web que visi- 
tan. Esto ilustra un tema importante acerca de los 
clientes y los servidores: no hay una designación 
fuerte O rápida de lo que es un cliente o un servidor 
de un sistema de comercio electrónico: esto depende 
realmente de la relación entre las entidades implica- 
das. Por ejemplo, el servidor Web actúa como un ser- 
vidor para los clientes que ejecutan un navegador, 
pero actúa como un cliente con el servidor de correo 
al cual le proporciona direcciones de correo para sus 
listas de correo. 


Unservidor de conferencia. Este es un servidor que 
administra conferencias. Lee en las contribuciones 
a la conferencia, visualiza estas contribuciones en 
una ventana asociada a una conferencia y borra cual- 
quier entidad que no esté actualizada. 


Servidores de bases de datos. Son servidores que 
administran las bases de datos asociadas a la apli- 
cación de comercio. Aquí se incluye la base de datos 
principal de libros, la cual contiene datos de cada 
libro; la base de datos de pedidos que contiene datos 
de los pedidos que han realizado los clientes, todos 
los que no se han cumplido tanto anteriores como 
actuales; la base de datos de clientes que contiene 
datos de los clientes de los vendedores de libros; y 
una base de datos que contiene datos de las ventas 
de libros concretos; esta base de datos es particu- 
larmente útil para muchos vendedores de libros en 
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la red, puesto que les permite publicar las listas de 
los libros más vendidos junto con las ofertas espe- 
ciales de esos libros. En muchos sistemas de comer- 
cio electrónico estas bases de datos son imple- 
mentadas en varios servidores de bases de datos 
especializados que son duplicados: tales bases de 
datos son vitales para el funcionamientode una com- 
pañía de comercioelectrónico: si el servidor de bases 
de datos funcionaba mal y no existen servidores 
duplicados, ocurría algo muy serio, ya que no ten- 
drían ingresos y los vendedores en red obtendrían 
una reputación muy pobre. Un punto importante a 
tener en cuenta sobre esta parte del sistema es que 
no hay razón para que una tecnología anterior, tal 
como un mainframe que ejecuta una monitorización 
de transacciones se pueda utilizar para funciones de 
bases de datos; en realidad muchos de los sistemas 
de comercio electrónico se componen de un servi- 


dor Web frontal que se comunica con un sistema ser- 
vidor no cliente. Este sistema servidor no cliente es 
el que lleva existiendo ya desde hace algún tiempo 
y se utilizaba para un procesamiento más conven- 
cional como es el de tomar pedidos por teléfono. 
Los servidores de bases de datos se mantendrán 
actualizados por medio de un software de sistemas 
que detecta cuando se va a aplicar una transacción 
a una base de datos: primero aplica la transacción a 
la base de datos que se está utilizando en ese 
momento y, a continuación, la aplica a todas las 
bases de datos duplicadas. 

Un servidor de monitorización. Este es el servidor 
que se utiliza para monitorizar la ejecución del sis- 
tema. Es utilizado por un administrador del sistema 
para comprobar el funcionamiento correcto del sis- 
tema y también para ajustarel sistema de manera que 
se archive un rendimiento óptimo. 


Existen varias tecnologías basadas en red que se utili- 
zan para las aplicacionesde comercio electrónico. Antes 
de describirlas merece la pena decir que muchas tecno- 
logías antiguas todavía se utilizan para este tipo de apli- 
cación; el mejor ejemplo es el uso de la tecnología de 
bases de datos relacionales para proporcionar almace- 
nes de datos a gran escala. 


Y] 
Er 
Muchas tecnologías antiguas todavía se utilizan 
para aplicaciones de comercio electrónico. 


28.6.1. Conexiones (sockets) 


Un socket es un tipo de conducto que se utiliza para 
conectarse a una computadora conectada a una red y 
basada en TCP/IP. El socket se configura de tal manera 
que los datos pueden ser bajados desde el cliente y 
devueltos al mismo. Los lenguajes de programación 
modernos, como Java, proporcionan servicios de alta 
calidad por medio de los cuales un socket se puede 
conectar mediante «programación» a una computado- 
ra cuya dirección de Internet sea conocida y donde los 
datos se puedan enviar por este conducto. La progra- 
mación necesaria para esto normalmente no es más com- 
plicada que la programación que se requiere para escribir 
y leer datos de un archivo. Los sockets son una imple- 
mentación a bajo nivel de la conectividad; dentro de las 
utilizaciones típicas de un socket están las aplicaciones 
de conferencia, donde una entrada a una conferencia se 
enviaría al servidor de conferencia que utiliza una con- 
figuración de sockets en el servidor. Los sockets son un 
mecanismo de bajo nivel, pero una forma muy eficien- 
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te de comunicar datos en un sistema distribuido que eje- 
cuta el protocolo TCP/TP. 


28.6.2. Objetos distribuidos 


¡ ¿Qué es un objeto 
- distribuido? 


Un objeto distribuido es aquel que reside en una com- 
putadora, normalmente un servidor, en un sistema dis- 
tribuido. Otras computadoras del sistema pueden enviar 
mensajes a este objeto como si residiera en su propia 
computadora. El software del sistema se hará cargo de 
varias funciones: localizar el objeto, recoger los datos 
que se requieren para el mensaje y enviarlos a través 
del medio de comunicación que se utiliza para el siste- 
ma. Los objetos distribuidos representan un nivel más 
alto de abstracción que las conexiones (sockets):a par- 
te de algún código de inicialización, el programador no 
es consciente del hecho de que el objeto reside en otra 
computadora. Actualmente existen tres tecnologías de 
objetos distribuidos en pugna: 


» RMI. Esta es la tecnología asociada al lenguaje de 
programación de Java. Es un enfoque Java puro en 
el que solo los programas escritos en ese lenguaje se 
pueden comunicar con un objeto RMI distribuido. 
Es la tecnología ideal para sistemas cerrados de Java; 
estos sistemas generalmente tendrán pocas conexio- 
nes o ninguna con otros sistemas. 


DCOM. Esta es una tecnología desarrollada por la 
compañía Microsoft y permite que programas escrl- 
tos en lenguajes tales como Visual Basic y Visual 
J++ (la variedad de Java desarrollada por Microsoft) 
se comuniquen con los objetos que están en compu- 
tadoras remotas. 
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CORBA. Esta es la tecnología de objetos distribui- 
dos más sofisticada. Fue desarrollada por un con- 
sorcio de compañías informáticas, clientes y 
compañías de software. La característica más impor- 
tante del enfoque CORBA es que es multilenguaje, 
donde los programadores pueden utilizar diferentes 
lenguajes de programación para enviar mensajes a 
objetos CORBA: las interfaces CORBA existen para 
lenguajes tales como Java, FORTRAN, LISP, Ada y 
Smalltalk. CORBA está al principio de su desarro- 
llo, sin embargo, amenaza con convertirse en la tec- 
nología dominante para objetos distribuidos. 


La principal ventaja de los objetos distribuidos sobre 
la de los sockets es el hecho de que como abarca ente- 
ramente el paradigma de orientación a objetos se pue- 
de emplear los mismos métodos de análisis y diseño que 
se utilizan para la tecnología de objetos convencional. 


28.6.3. Espacios 


Esta es una tecnología que se encuentra en un nivel de 
abstracción incluso más alto que los objetos distribui- 
dos. Fue desarrollada por David Gelemter, un profesor 
de la Universidad de Yale. La tecnología de espacios 
concibe un sistema distribuido en base a un gran alma- 
cén de datos persistentes donde las computadoras de un 
sistema distribuido puede leer o escribir. No concibe el 
sistema distribuido como una serie de programas que 
pasan mensajes a los demás utilizando un mecanismo 
como los sockets, o como una serie de objetos distri- 
buidos que se comunican utilizando métodos. Por el 
contrario, la tecnología de espacios conlleva procesos 
como escribir, leer o copiar datos a partir de un alma- 
cén persistente. Un programador que utiliza esta tecno- 
logía no se preocupa por detalles como dónde están 
almacenados los datos, qué proceso va a recoger los 
datos y cuándo los va a recoger. 

Esta tecnología se encuentra sólo al principio, aun- 
que las implementaciones llevan ya disponibles duran- 
te algún tiempo para lenguajes como C y C++; sin 
embargo, la implementación de la tecnología dentro de 
Java como Javaspaces debería asegurar que cada vez se 
utilizará más para las aplicaciones principales. 


28.6.4. CGI 


El término CGI (Common Gateway Interface) signifi- 
ca Interfaz común de pasarela. Es la interfaz con el ser- 
vidor Web al cual se puede acceder mediante los 
programas que se ejecutan en el servidor. Gran parte de 
la interactividad asociada a las páginas Web se imple- 
menta programando el acceso a la CGI. Por ejemplo, 
cuando el usuario de un navegador accede a una págl- 
na que contiene un formulario, éste lo rellena y lo envía 
al servidor Web, programa que accede al CGI, procesa 
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el formulario, y lleva a cabo la funcionalidad asociada 
al formulario; por ejemplo, recuperando los datos soli- 
citados en el formulario. La programación CGI se pue- 
de llevar a cabo en varios lenguajes de programación, 
aunque el lenguaje seleccionado ha sido Perl, lenguaje 
de procesamiento de cadenas, existen otros entre los que 
se incluyen, por ejemplo, Java y C++, que contienen los 
servicios para el procesamiento CGI. Recientemente los 
que desarrollan Java han proporcionado a los progra- 
madores el servicio de utilizar Java para este tipo de 
programación que utiliza la tecnología conocida como 
sewlets. Estos trozos pequeños de código Java son inser- 
tados en un servidor de Web y se ejecutan cuando ocu- 
rre un suceso, como enviar un formulario. Los servlets 
ofrecen un alto grado de portabilidad sobre otros len- 
guajes de programación. 


28.6.5. Contenido ejecutable 


Este es el término que se aplica a la inclusión en una pági- 
na Web de un programa que se ejecuta cuando la página 
es recuperada por un navegador. Este programa puede 
llevar a cabo un número diverso de funciones entre las 
que se incluyen la animación y la presentación de un for- 
mulario al usuario para insertar datos. Existen varias tec- 
nologías que proporcionan servicios para insertar 
contenido ejecutable en una página Web. Aquí se inclu- 
yen applets, Active X y Javascript. Un applet es un pro- 
grama escrito en Java que interactúa con una página Web. 
Lo importante a señalarde esta tecnología es que es por- 
tátil: el código Java se puede mover fácilmente desde un 
sistema operativo a otro, pero es potencialmente insegu- 
ro. La razón de por qué los applets son inseguros es que 
se pueden utilizar como medio de transmisión de virus y 
otros mecanismos de acceso a una computadora. Cuan- 
do una página de navegador que contiene un applet es 
descargadapor un navegador, es lo mismo que cargar un 
programa en la computadoracliente que ejecuta el nave- 
gador. Afortunadamente los diseñadores de Java desa- 
rrollaron el lenguaje de tal manera que es inmensamente 
difícil escribir applets que provoquen violaciones en la 
seguridad. Desafortunadamentela solución que se adop- 
tó evita acceder a los recursos de una computadoraclien- 
te o ejecutar otro programa en la computadora. Aunque 
se han hecho muchas mejoras en los applets que permi- 
ten un acceso limitado, el modelo principal del uso de 
applets está restringido a este modo de ejecución. 

Active X es otra tecnología de contenido ejecutable 
que fue desarrollada por Microsoft. De nuevo se trata 
de un código de programa insertado en una página Web; 
la diferencia principal entre esta tecnología y los applets 
es el hecho de que estos trozos de código se pueden 
escribir en diferentes lenguajes como Visual Basic y 
C++, Esta forma de contenido ejecutable también sufre 
de posibles problemas de seguridad. 

Javascript es un lenguaje de programación interpre- 
tado y sencillo que se inserta directamente en una pági- 
na Web. Se diferencia de las soluciones de Active X y 
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applets en que el código fuente de cualquier programa 
de guiones de Java se integra en una página Web en vez 
de en el código de objetos como ocurre con los applets 
y Active X. Javascript es un lenguaje sencillo que se 
utiliza para una programación relativamente a bajo nivel. 


28.6.6. Paquetes cliente/servidor 


Este término describe las colecciones de software que 
normalmente llevan a cabo algún tipo de procesamien- 
to de sistemas. A continuación, se muestra un grupo de 
ejemplos típicos de paquetes de software: 


. Paquetes de reproducción de datos. Este tipo de soft- 
ware realiza una transacción en la base de datos y la 
aplica a un número de bases de datos reproducidas, 
evitando así acceder a estas bases de datos hasta que 


estén todas en sincronización. 


» Paquetes de seguridad. Estos son paquetes que moni- 
torizan el tráfico dentro de un sistema distribuido y 
avisan al administrador de sistemas de la aparición 
de cualquier violación posible en la seguridad. Por 
ejemplo, el hecho de que alguien intente entrar en un 
sistema con una contraseña sin reconocer. 


» Monitores de transacciones. Estos son paquetes de 
software que administran las transacciones que tie- 
nen lugar dentro de un sistema distribuido y ase- 
guran que se devuelvan los datos correctos como 
resultado de una transacción y en el orden correcto. 
Muchas de las funciones de estos monitores tienen 
que ver con asegurar que los resultados correctos 
se devuelvan incluso en el entorno en donde 
podrían aparecer errores de hardware o de trans- 
misión. 


Antes de observar algunos de los principios del diseño 
que se utilizan en el desarrollo de sistemas distribuidos, 
particularmente de sistemas de comercio electrónico, 
merece la pena reiterar lo que se ha señalado anterior- 
mente: a nivel de análisis hay poca diferencia entre un 
sistema distribuido y un sistema local, y se basa en que 
el modelo de análisis de un sistema no contendrá nin- 
gún dato de diseño como el hecho de que tres compu- 
tadoras, y no una solo, están llevando a cabo algún 
procesamiento. Esto significa que el desarrollador de 
un sistema distribuido se enfrentará normalmente con 
un modelo de objetos o un modelo funcional similar al 
que se mostró en las primeras partes de este libro; esta 
descripción irá acompañada de algunos de los tipos de 
computadoras y de hardware de redes que se van a uti- 
lizar. El proceso de diseño implica transformarel mode- 
lo de análisis en algún modelo físico que se implementa 
en los elementos de hardware del sistema. 


Gn 
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Recuerde que durante el análisis existe poca diferencia 
entre una aplicación de comercio electrónico 
y Una convencional. 


Es necesario que el diseñador de sistemas distribui- 
dos conozca una serie de principios de diseño. El resto 
de esta sección muestra un esquema de los mismos. 


28.7.1. Correspondencia del volumen de trans- 
misión con los medios de transmisión 


Este es uno de los principios más obvios. Esto signifi- 
ca que para un tráfico denso de datos en un sistema dis- 
tribuido se deberían utilizar medios de transmisión 
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rápidos (y caros). El proceso de asignar tales medios 
normalmente tiene lugar después de haber tomado deci- 
siones sobre la potencia de procesamiento de distribu- 
ción en un sistema y, algunas veces, conlleva unas ligeras 
iteraciones al final de la fase de diseño. 


28.7.2. Mantenimiento de los datos más usados 
en un almacenamiento rápido 


Este principio también es obvio. Requiere que el dise- 
ñador examine los patrones de datos en un sistema y 
asegure que los datos a los que se accede frecuentemente 
se guarden en algún medio de almacenamiento rápido. 
En muchos sistemas tales datos pueden constituir no 
más del 5 por 100 de los datos originales almacenados 
en el sistema, y de esta manera permite utilizar con fre- 
cuencia las estrategias que conllevan el almacenamien- 
to de estos datos dentro de la memoria principal. 


28.7.3, Mantenimiento de los datos cerca 
de donde se utilizan 


Este principio de diseño intenta reducir el tiempo que 
pasan los datos en medios lentos de transmisión. Muchos 
de estos sistemas son en donde los usuarios acceden con 
frecuencia a un subconjunto de datos. Por ejemplo, un 
sistema distribuido usado en una aplicación bancaria 
contendríabases de datos con datos de las cuentas de los 
clientes, en donde la mayor parte de las consultas a las 
bases de datos de las sucursales las realizarán los clien- 
tes de esa sucursal; entonces, si los datos de un sistema 
bancario se distribuyen a los servidores de las sucursa- 
les, y los datos asociados a los clientes de esa sucursal 
están en esa sucursal, el resto de los datos podrían estar 
en otros servidores con otras ubicaciones, y cualquier 
consulta que se originara sobre los datos se tendría que 
comunicar a través de líneas lentas de transmisión. 
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28.7.4, Utilización de la duplicación de datos 
todo lo posible 


La duplicación consiste en mantener múltiples copias 
de datos en un sistema al mismo tiempo. Existen muchas 
razones para la duplicación de datos. La primera es que 
hay que asegurar la redundancia que permite que un sis- 
tema distribuido continúe funcionando aun cuando una 
computadora con datos importantes quede fuera de ser- 
vicio normalmente por un mal funcionamientodel hard- 
ware. La otra razón es que proporciona una forma de 
implementarel principio dilucidado en la sección ante- 
rior: el de asegurar que los datos estén ubicados cerca 
de donde se utilizan. Por ejemplo, una compañía hote- 
lera con una base central de reservas que hace el segui- 
miento de todas las reservas de las habitaciones para 
todos sus hoteles. Es posible que esta compañía tenga 
dos puntos de contacto para clientes que deseen hacer 
las reservas: los hoteles en sí y una oficina central de 
reservas. Una forma de asegurar el alto rendimiento es 
duplicandolos datos asociados a un hotel en particular 
y guardar los datos en el servidor ubicado en el hotel. 
Esto significaque cualquier reserva realizada por el hotel 
solo necesitará acceder a una base de datos local y no 
requerirá ningún tráfico en la línea lenta de transmisión. 
Esto suena a un principio muy simple de implementa- 
ción sencilla. Desafortunadamente, las cosas nunca son 
tan simples. En el ejemplo de las reservas de hoteles no 
hay necesidad de que las bases de datos asociadas a los 
hoteles se comuniquen con la base de datos central. La 
razón que apoya esto es el hecho de que también habrá 
clientes que utilicen la oficina central de reservas, así 
como clientes realizando reservas de habitaciones que 
ofrecen los mismos hoteles. A menos que haya coordi- 
nación entre la base de datos de la oficina central de 
reservas y las bases de datos individuales duplicadas de 
cada hotel, surgirán problemas: por ejemplo, el hecho 
de decir que hay una habitación libre en un momento 
concretoen un hotel a un cliente que utiliza el servicio 
central de reservas aun cuando esa habitación ya ha sido 
reservada por otro cliente que ha llamado directamen- 
te al hotel. 


e, 
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la duplicación controlada de datos puede tener un efecto 
importante en el rendimiento de un sistema distribuido. 


El problema anterior implica que en un sistema don- 
de hay una relación dinámicaentre las bases de datos indi- 
viduales existe la necesidad entonces de que cada base de 
datos mantenga informadas de los cambios a otras bases 
de datos, y de que aseguren que los cambios se reflejen 
en todos los datos duplicados. Esto también implica la 
aparición de retrasos porque las transacciones permane- 
cerán en cola esperando a que la base de datos se sincro- 
nice con otras bases de datos. Esto no significa que se 
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tenga que utilizar la duplicación de datos, lo que signifi- 
ca es que se necesita un diseño cuidadoso para minimizar 
la cantidad de gastos asociados a él en las transmisiones. 

Hay que señalar que en los sistemas distribuidosdon- 
de existe menos relación dinámica entre los datos, se 
pueden emplear estrategias más simples que eliminen 
muchos de los gastos. Por ejemplo, un banco normal- 
mente lleva a cabo transacciones una vez al día en las 
bases de datos de los clientes y normalmente después 
del cierre del negocio. Esto significaque un sistema ban- 
cario distribuido puede duplicar datos en sus sucursa- 
les y solamente puede volver a copiar los datos 
cambiadosen las bases de datos una vez al día: no habría 
necesidad de coordinar las bases de datos con frecuen- 
cia durante el día de trabajo. 

Habría que señalar también que esta subsección ha 
tratado la duplicación de datos en función de mantener 
los datos cerca de los usuarios para reducir el tiempo de 
transmisión con medios lentos. Hay otras razones para 
duplicar los datos, por ejemplo una base de datos que 
se utiliza mucho tendrá colas de transacciones prepara- 
das y esperandoa ejecutarse. Estas colas se pueden redu- 
cir disfrutando de bases de datos idénticas mantenidas 
en otros servidores de bases de datos concurrentes. 


28.7.5. Eliminar cuellos de botella 


En un sistema distribuido un servidor se convierte con 
frecuencia en un cuello de botella: tiene que manipular 
tanto tráfico que se construyen grandes colas de transac- 
ciones esperandoa ejecutarse, con el resultadode que los 
servidores que están esperando los resultados del proce- 
samiento estarán, en el mejor de los casos, ligeramente 
cargados y, en el peor, inactivos. La estrategia normal 
para manipular cuellos de botella es compartir la carga 
de procesamientoentre los servidores, normalmente ser- 
vidores físicamente cerca del que está sobrecargado. 


28.7.6. Minimizar la necesidad de un gran 
conocimiento del sistema 


Los sistemas distribuidos suelen necesitar conocer el esta- 
do del sistema completo, por ejemplo, podría ser que 
necesitaran conocer la cantidad de registros de una base 
de datos central. El hecho de necesitar este conocimien- 
to genera más tráfico reduciendo así la eficiencia de un 
sistema, ya que generará tráfico extra a lo largo de las 
líneas de transmisión. El diseñador de un sistema distri- 
buido en primer lugar necesita minimizar que el sistema 
dependa de datos globales, y entonces asegurar que el 
conocimiento necesario se comunique rápidamente a 
aquellos componentes del sistema que lo requieran. 


28.7.7. Agrupar datos afines en la misma 
ubicación 
Los datos que están relacionados deberían de estar den- 


tro del mismo servidor. Por ejemplo, en una aplicación 
de reservas en un sistema de vacaciones, los paquetes 
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individuales de vacaciones deberían de estar cerca de 
los datos que describen las reservas actuales de ese 
paquete. Ubicar por separado los datos en diferentes ser- 
vidores asegura que los medios de baja transmisión y 
muy cargados se cargarán incluso más. El diseñador de 
un sistema distribuido debe asegurarse de que los datos 
relacionados gracias al hecho de que se suelen recupe- 
rarjuntos tendrán que residir lo más cerca posible, pre- 
feriblemente en el mismo servidor, o si no, y no de 
manera tan preferible, en servidores conectados a tra- 
vés de medios de transmisión rápidos tales como los 
medios utilizados en una red de área local. 


28.7.8. Considerar la utilización de servidores 
dedicados a funciones frecuentes 


Algunas veces se puede lograr un mayor rendimiento 
mediante la utilización de un servidor de empleo espe- 
cífico para una función en particular en lugar de, por 
ejemplo, un servidor de bases de datos. 


28.7.9. Correspondenciade la tecnología con las 
exigencias de rendimiento 


Muchas de las tecnologías que se estudian en este capí- 
tulo tienen pros y contras, y un factor importante aquí 
son las demandas de rendimiento de una tecnología en 
particular. 

Por ejemplo, como medio de comunicación, las 
conexiones (sockets) normalmente son un medio de 
comunicación mucho más rápido que los objetos dis- 
tribuidos. Cuando el diseñadorelige una tecnología debe 
de tener conocimiento de la transmisión y de las cargas 
de procesamiento que conlleva, y seleccionar una tec- 
nología que minimice estas cargas. 


28.7.10. Empleo del paralelismo todo lo posible 


Una de las ventajas principales de la tecnología clien- 
te/servidor es el hecho de que se pueden añadir servi- 
dores y, hasta cierto punto, elevar el rendimiento del 
sistema. Muchas funciones del comercio electrónico 
pueden beneficiarse de la ejecución que están llevando 
a cabo diferentes servidores en paralelo. Esta no es una 
decisión sencilla. Mediante el empleo de varios servi- 
dores, el diseñador está creando la necesidad de que 
estos servidores se comuniquen, por ejemplo, un servi- 
dor puede que necesite a otro para completar una tarea 
en particular antes de finalizar la suya propia. Esta comu- 
nicación puede introducir retrasos y, si el diseñador no 
tiene cuidado, pueden negar los avances de rendimien- 
to que se han logrado utilizando el paralelismo. 


28.7.11. Utilización de la compresión de datos 
todo lo posible 


Se dispone de un grupo de algoritmos que comprimen 
datos y que reducen el tiempo que tardan los datos en 
transferirse entre un componente de un sistema distri- 
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buido y otro componente. El único gasto que se requie- 
re para utilizar esta técnica es tiempo del procesador y 
la memoria necesaria para llevar a cabo la compresión 
en la computadora del emisor y la descompresión en la 
computadora del receptor. 


28.7.12. Diseño para el fallo 


¿Por qué puede ser 
catastrófico un tallo de 
hardware en un sistema de 
comercio electrónico? 


Un fallo de hardware en la mayoría de los sistemas de 
comercio electrónico es una catástrofe: para los siste- 
mas de ventas en red esto es equivalente a echar el cie- 
rre a los clientes. Una parte importante del proceso de 
diseño es analizar los fallos que podrían aparecer en un 
sistema distribuido y diseñar el sistema con suficiente 
redundancia como para que dicho fallo no afecte seria- 
mente y, en el mejor de los casos, que se pueda redu- 
cir el tiempo de respuesta de ciertas transacciones. Una 
decisión normal que suele tomar el diseñador es dupli- 
car los servidores vitales para el funcionamiento de un 
sistema distribuido. Una estrategia en los sistemas de 
alta integridad es que un servidor se reproduzca tres 
veces y que cada servidor lleve a cabo la misma tarea 
en paralelo. Cada servidor produce un resultado a com- 
parar. Si los tres servidores aceptan el resultado, éste 
pasa a cualquier usuario o servidor que lo requiera; si 
uno de los servidores no está de acuerdo, entonces sur- 
ge un problema y el resultado de la mayoría se pasa 
informando al administrador de sistemas del posible 
problema. La duplicación de servidores como estrate- 
gia de mitigación de fallos puede utilizarse junto con 
el diseño de un sistema para lograr el paralelismo en 
las tareas. 


28.7.13. Minimizar la latencia 


Cuando los datos fluyen de una computadora a otra en 
un sistema distribuido a menudo tiene que atravesar 
otras computadoras. Algunas de estas computadoras 
puede que ya tengan unos datos que expidan funciona- 
lidad; es posible que otras procesen los datos de algu- 
na manera. El tiempo que tardan las computadoras es 
lo que se conoce como latencia. Un buen diseño de sis- 
tema distribuido es el que minimiza el número de com- 
putadoras intermediarias. 


28.7.14. Epílogo 


Este ha sido un estudio breve aunque necesario, y se 
han tratado las diferentes estrategias de diseño que se 
utilizan en los sistemas distribuidos que implementan 
las funciones del comercio electrónico. Un punto impor- 
tante a tener en cuenta antes de abandonar esta sección 
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es que una estrategia puede militar contra otra, mini- 
mizar la latencia y duplicar bases de datos pueden ser 
dos estrategias opuestas: incrementar el número de bases 


El incremento masivo en la utilización pública de sis- 
temas distribuidos ha dado lugar a algunos problemas 
graves con la seguridad. Los sistemas distribuidos ante- 
riores se suelen localizar en un lugar físico utilizando 
tecnologías tales como redes de área local. Dichos sis- 
temas estaban físicamenteaislados de los usuarios exter- 
nos y como consecuencia la seguridad, aunque es un 
problema, no era un problema enorme como lo es aho- 
ra para los sistemas de comercio electrónico a los que 
pueden acceder miembros de usuarios que emplean un 
navegador. 

A continuación, se detallan algunas de las intrusio- 
nes típicas en la seguridad que pueden ocurrir: 


Un intruso monitoriza el tráfico de una línea de trans- 
misión y recoge la información confidencial que 
genera un usuario. Por ejemplo, el intruso podría leer 
el número, la fecha de caducidad y el nombre del 
titular de una tarjeta de crédito. Y, a continuación, 
puede utilizar esta información para realizar pedidos 
en Internet. 


Un intruso podría entrar en un sistema distribuido, 
acceder a la base de datos y cambiar la información 
de la misma. Por ejemplo, podría cambiar el balance 
de una cuenta en un sistema bancario en la red. 


»N 
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CLAVE 


Ahora que Internet ya se estó utilizando 
para muchas mós aplicaciones, la seguridad 
se convierte en un problemaimportante. 


Un intruso podría leer una transacción que pasa por 
alguna línea de transmisión y alterar los datos den- 
tro de ella en beneficio propio. Por ejemplo, podría 
alterar la instrucciónde un cliente de un sistemaban- 
cario en red para transferir los datos de una cuenta a 
otra para que la cuenta del intruso sea la que tiene 
lugar en la transferencia. 


Un ex empleado contrariado de una compañía envía 
un programa al sistema distribuido de la compañía 
monopolizandoel tiempo del procesador del sistema, 
pasando gradualmente de servidor a servidor hasta 
que el sistema queda exhausto y acaba parándose. 
Esta es una forma de ataque conocido como dene- 
gación de ataque al servicio. 

Un empleado contrariado de una compañía envía un 
programa a un sistema distribuido el cual borra los 
archivos importantes del sistema. 
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de datos duplicadas incrementa la latencia de un siste- 
ma; como consecuencia, el diseño de sistemas distri- 
buidos, más que otra cosa, es un arte. 


Estas son entonces algunas de las intrusiones que pue- 
den tener lugar dentro de un sistema distribuido; estas 
intrusiones cada vez son más frecuentes, ya que gran 
parte de la transmisiónen los sistemas de comercio elec- 
trónico ocurren en una Internet públicamente accesible 
que utiliza protocolos públicamente disponibles. 

Una de las tareas más importantes del diseñador de 
sistemas distribuidos es diseñar un sistema con el pro- 
pósito de minimizar la posibilidad de éxito de las ins- 
trucciones de alto riesgo. Para poder llevarlo a cabo se 
necesita utilizar una serie de tecnologías. En la siguien- 
te sección se hace una relación detallada de estas tec- 
nologías. 


28.8.1. Encriptación 


Encriptación es el término que se utiliza para referirse 
al proceso de transformar datos o texto (texto en claro) 
para ser ilegible; además, debería resultar virtualmente 
imposible que un intruso pueda descifrarlo. A conti- 
nuación, se detalla el proceso de utilización de esta tec- 
nología: 


1. 


¿Qué es la encriptación y 
por qué es útil? 


La computadora emisora transforma el texto en 
alguna forma ilegible; este proceso se conoce como 
encriptación. 

. Los datos encriptados entonces se envían a través de 
líneas de transmisión insegura. 

La computadora receptora procesa el texto encrip- 
tado y lo transforma a su forma original. Este pro- 
ceso se conoce como desencriptación. 


7 


Se utilizan dos formas de encriptación. La primera 
es la encriptación simétrica, donde un mensaje se trans- 
forma en una forma encriptada utilizando una cadena 
conocida como clave: se aplica alguna transformación 
en el mensaje utilizando la clave. Entonces la clave se 
comunica al receptor a través de algún medio seguro y 
es utilizado por el receptor para llevar a cabo la desen- 
criptación. 

La encriptación simétrica es eficiente pero padece 
un problema importante: si un intruso descubre la cla- 
ve, podría descubrir fácilmente el mensaje encripta- 
do. La encriptación de clave pública es una solución 
a este problema, donde se utilizan dos claves de 
encriptación: una conocida como clave pública y otra 
como clave privada. Un usuario que desea recibir men- 
sajes encriptados publicará su clave pública. Otros 
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usuarios que deseen comunicarse con el usuario uti- 
lizarán esta clave para encriptar cualquier mensaje; 
los mensajes entonces son desencriptados mediante 
la clave privada cuando los recibe el usuario original. 
Esta forma de encriptación tiene la ventaja principal 
de que la gestión de claves es sencilla: la clave pri- 
vada nunca se envía a nadie. Un intruso que monito- 
riza los datos encriptados que viajan por algún medio 
de transmisión es incapaz de decodificar ningún men- 
saje puesto que no tienen acceso posible a la clave 
privada. El inconveniente principal de esta forma de 
encriptación es que se necesita una gran cantidad de 
recursos para llevar a cabo el proceso de desencrip- 
tación. Debido a esta clave pública, los sistemas nor- 
malmente se limitan a envíos cortos de texto o a un 
texto pensado para ser altamente seguro. También se 
utiliza para la autenticación, la cual utiliza una técni- 
ca conocida como firmas digitales, que se describen 
en la sección siguiente. 

La tecnología principal que se utiliza en Internet 
para la encriptación simétrica es la capa de sockets 
seguros (SSL). Esta es una tecnología que se utiliza 
para encriptar datos confidenciales tales como los 
números de las tarjetas de crédito que viajan desde el 
navegador a un servidor Web, o desde una aplicación 
a otra. 


28.8.2. Funciones de compendio de mensajes 


Una función de compendio de mensajes es un algorit- 
mo que genera un número grande — normalmenteentre 
128 y 256 bits de longitud — que representa un com- 
pendio o resumen de los caracteres de un mensaje. Tie- 
ne la propiedad de que si el mensaje cambia y se vuelve 
a aplicarel algoritmo, el número entonces cambia. Exis- 
ten muchas utilizaciones de las funciones de compen- 
dio de mensajes. Un uso común es detectar los cambios 
en un mensaje, por ejemplo, el hecho de que una tran- 
sacción financiera se haya modificado en la transmisión 
con objeto de favorecer al que modifica. Antes de enviar 
un mensaje se aplica la función de compendio de men- 
saje y se forma un número grande. El mensaje enton- 
ces seenvía con el número añadido al final. La función 
de compendio de mensaje se aplica en el receptor y el 
número resultante se compara con el que se envió. Si 
los dos son iguales el mensaje entonces no se ha modi- 
ficado: si no son iguales el mensaje ha sido modificado 
durante la transmisión. 


28.8.3. Firmas digitales 


Una firma digital, como su propio nombre sugiere, es 
una forma de que el emisor de un mensaje se pueda 
identificar con el receptor de tal manera que el recep- 
tor pueda confiar en que el mensaje fue enviado real- 
mente por el emisor. La encriptación de clave pública 
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es la que se utiliza normalmente para esto. Conside- 
remos una forma de llevar a cabo este proceso: dos 
usuarios de computadoras A y B quieren comunicar- 
se, y A quiere asegurarse de que se está comunicando 
con B. Para poder hacer esto, B necesita tener una cla- 
ve pública y una privada, y tener conocimiento de cuál 
es la clave pública. A envía un mensaje a B con un tex- 
to en el que A pide a B una encriptación utilizando su 
clave privada. Este texto entonces es encriptado por B 
y devuelto a A quien lo descifra utilizando la clave 
pública que B le ha proporcionado. Siel mensaje es el 
mismo que el que se envió, B es entonces quien dice 
que es, pero, si no lo es, B entonces no ha demostra- 
do su identidad. Este esquema comparte todas las ven- 
tajas de cualquier método de clave pública en donde 
la clave privada es segura; sin embargo, puede ser ata- 
cado por cualquiera que desee establecer falta de con- 
fianza entre un emisor y un receptor. Esto se puede 
hacer alterando el mensaje encriptado que se ha devuel- 
to al emisor. 


28.8.4. Certificaciones digitales 


Una certificación digital es un documento electrónico 
que proporciona al usuario un alto de grado de confianza 
con una organización O persona con la que estén tra- 
tando. Se pueden utilizar cuatro tipos de certificacio- 
nes: 


Certificaciones de una autoridad de certificación. 
Una autoridad de certificación es una organización 
que proporciona certificados digitales, tales como 
estas dos organizaciones: Canada Post Corporation 
y los servicios postales de US. 


Certificaciones del servidor. Estas certificaciones 
contienen datos tales como la clave pública del ser- 
vidor, el nombre de la organización que posee el ser- 
vidor y la dirección del servidor en Internet. 


Certificaciones personales. Estas son las certifica- 
ciones asociadas a un individuo. Contendrán infor- 
mación física tal como la dirección del individuo 
junto con la información relacionada con la compu- 
tadora como la clave pública y la dirección de correo 
electrónico de la persona. 


Certificaciones del editor de software. Estos son cer- 
tificados que proporcionan confianza en que el soft- 
ware ha sido producido por una compañía de 
software específica. 


Como ejemplo para el funcionamiento de estas cer- 
tificaciones tomemos el de las certificaciones del servi- 
dor. Un servidor que utiliza la capa de sockets seguros 
(SSL) debe de tener un certificado SSL. Este certifica- 
do contiene una clave pública. Cuando un navegador se 
conecta con el servidor se utiliza entonces esta clave 
pública para codificar la interacción inicial entre el ser- 
vidor y el navegador. 
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28.9.1. Introducción 


En lugar de visualizar el software como una aplicación 
monolítica que deberá de implementarse en una máqui- 
na, el software que es adecuado para una arquitectura 
posee varios componentes distintos que se pueden aso- 
ciar al cliente o al servidor, o se pueden distribuir entre 
ambas máquinas: 


Componente de interacción con el usuario y pre- 
sentación. Este componente implementa todas las fun- 
ciones que típicamente se asocian a una interfaz gráfica 
de usuario (1GU). 

Componente de aplicación.Este componente imple- 
menta los requisitos definidos en el contexto del domi- 
nio en el cual funciona la aplicación. Por ejemplo, una 
aplicación de negocios podría producir toda una gama 
de informes impresos basados en entradas numéricas, 
cálculos, información de una base de datos y otros aspec- 
tos. Una aplicación de software de grupo podría pro- 
porcionar funciones para hacer posible la comunicación 
mediante boletines de anuncios electrónicos o de correo 
electrónico, y en nuestro caso de estudio esto conlleva- 
ría la preparación de informes como los que describen 
las ventas de libros. En ambos casos, el software de la 
aplicación se puede descomponer de tal modo que algu- 
no de los componentes residan en el cliente y otros resi- 
dan en el servidor. 


Referencia 


la PFR del grupo de noticias comp.client-server se puede 
encontrar en la página 
www.faqs.org/faqs/client-server-faq 


Componente de gestión de bases de datos. Este 
componente lleva a cabo la manipulación y gestión de 
datos por una aplicación. La manipulación y gestión 
de datos puede ser tan sencilla como la transferencia de 
un registro, o tan compleja como el procesamiento de 
sofisticadas transacciones SQL. 

Además de estos componentes, existe otro bloque de 
construcción del software, que suele denominarse soft- 
ware intermedio en todos los sistemas C/S. El softwa- 
re intermedio se describió en la Sección 28.2.3. Orfali 
[ORF99] y sus colegas se han referido al software inter- 
medio como «el sistema nervioso de un sistema clien- 
te/servidor». 


¿- 


El software intermedio establece la infraestructura 
que hace posible que los componentes 
diente /servidor interoperen. 


28.9.2. Distribución d e componentes de software 


Una vez que se han determinado los requisitos básicos 
de una aplicación cliente/servidor, el ingeniero del soft- 
ware debe decidir cómo distribuir los componentes de 
software descritos en la Sección 28.1.1 entre el cliente 
y el servidor. Cuando la mayor parte de la funcionali- 
dad asociada a cada uno de los tres componentes se le 
asocia al servidor, se ha creado un diseño de servidor 
pesado (grueso). A la inversa, cuando el cliente imple- 
menta la mayor parte de los componentes de interac- 
ción/presentación con el usuario, de aplicación y de 
bases de datos, se tiene un diseño de cliente pesado 
(grueso). 

Los clientes pesados suelen encontrarse cuando se 
implementan arquitecturas de servidor de archivo y de 
servidor de base de datos. En este caso el servidor pro- 
porciona apoyo para la gestión de datos, pero todo el 
software de aplicación y de IGU reside en el cliente. 
Los servidores pesados son los que suelen diseñarse 
cuando se implementan sistemas de transacciones y de 
trabajo en grupo. El servidor proporciona el apoyo de 
la aplicación necesario para responder a transacciones 
y comunicaciones que provengan de los clientes. El soft- 
ware de cliente se centra en la gestión de IGU y de 
comunicación. 


Y 
da 
Un cliente «pesado» implementa la mayoría de las aplicaciones 


especificas de la aplicación en el cliente. Un cliente «figero» 
relega la mayor parte del procesoal servidor. 


Se pueden utilizar clientes y servidores pesados para 
ilustrar el enfoque general de asignación de compo- 
nentes de software de cliente/servidor. Sin embargo, un 
enfoque más granular para la asignación de componentes 
de software define cinco configuraciones diferentes. 


Presentación distribuida. En este enfoquecliente/ser- 
vidor rudimentario, la lógica de la base de datos y la lógica 
de la aplicación permanecen en el servidor, típicamente 
en una computadora central. El servidor contiene tam- 
bién la lógica para preparar información de pantalla, 
empleando un software tal como CICS. Se utiliza un soft- 
ware especial basado en PC para transformar la infor- 
mación de pantalla basada en caracteres que se transmite 
desde el servidor en una presentación IGU en un PC. 


+ ¿Cuáles son las opciones de 
configuración poro los 


componentes de software 
cliente /servidor? 


Presentación remota. En esta extensión del enfoque 
de presentación distribuida, la lógica primaria de la base 
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de datos y de la aplicación permanecen en el servidor, 
y los datos enviados por el servidor serán utilizados por 
el cliente para preparar la presentación del usuario. 


Lógica distribuida. Se asignan al cliente todas las 
tareas de presentación del usuario y también los proce- 
sos asociados a la introducción de datos tales como la 
validación de nivel de campo, la formulación de con- 
sultas de servidor y las solicitudes de informaciones de 
actualizaciones del servidor. Se asignan al servidor las 
tareas de gestión de las bases de datos, y los procesos 
para las consultas del cliente, para actualizaciones de 
archivos del servidor, para control de versión de clien- 
tes y para aplicaciones de ámbito general de la empresa. 

Gestión de datos remota. Las aplicaciones del ser- 
vidor crean una nueva fuente de datos dando formato a 
los datos que se han extraído de algún otro lugar (por 
ejemplo, de una fuente de nivel corporativo). Las apli- 
caciones asignadas al cliente se utilizan para explotar 
los nuevos datos a los que se ha dado formato mediante 
el servidor. En esta categoría se incluyen los sistemas 
de apoyo de decisiones. 

Bases de datos distribuidas. Los datos de que consta 
la base de datos se distribuyen entre múltiples clientes 
y servidores. Consiguientemente, el cliente debe de 
admitir componentes de software de gestión de datos 
así como componentes de aplicación y de IGU. 


Durante los Últimos años se ha dado mucha impor- 
tancia a la tecnología de cliente ligero. Un cliente lige- 
ro es la llamada «computadorade redes» que relega todo 
el procesamiento de la aplicación a un servidor pesado. 
Los clientes ligeros (computadoras de red) ofrecen un 
coste por unidad sustancialmente más bajo a una pér- 
dida de rendimiento pequeña O nada significativa en 
comparación con las computadoras de sobremesa. 


28.9.3. Líneas generales para la distribución de 
componentes de aplicaciones 


Aun cuando no existen reglas absolutas que describan 
la distribución de componentes de aplicaciones entre el 
cliente y el servidor, suelen seguirse las siguientes líne- 
as generales: 


El componente de presentaciónlinteracción suele 
ubicarse en el cliente, La disponibilidad de entornos 
basados en ventanas y de la potencia de cómputo nece- 
saria para una interfaz gráfica de usuario hace que este 
enfoque sea eficiente en términos de coste. 


Sies necesario compartir la base de datos entre múl- 
tiples usuarios conectados a través de la LAN, enton- 
ces la base de datos suele ubicarse en el servidor. El 
sistema de gestión de la base de datos y la capacidad de 
acceso a la base de datos también se asignan al servi- 
dor, junto con la base de datos física. 

Los datos estáticos que se utilicen deberían de asig- 
narse al cliente. Esto sitúa los datos más próximos al 
usuario que tiene necesidad de ellos y minimiza un trá- 
fico de red innecesario y la carga del servidor. 
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El resto de los componentes de la aplicación se dig. 
tribuye entre cliente y servidor basándose en la distri- 
bución que optimice las configuraciones de cliente y 
servidor y de la red que los conecta. Por ejemplo, la 
implementación de una relación mutuamente excluyen- 
te implica una búsqueda en la base de datos para deter 
minar si existe un registro que satisfaga los parámetros 
de una cierta trama de búsqueda. Si no se encuentra nin- 
gún registro, se emplea una trama de búsqueda alterna: 
tiva, Sila aplicación que controla esta trama de búsqueda 
está contenida en su totalidad en el servidor, se minimi- 
za el tráfico de red. La primera transmisión de la red des- 
de el cliente hacia el servidor contendría los parámetros 
tanto para la trama de búsqueda primaria como para la 
trama de búsqueda secundaria. La lógica de aplicación 
del servidor determinaría si se requiere la segunda bús- 
queda. El mensaje de repuesta al cliente contendría el 
registro hallado como consecuencia bien de la primera 
O bien de la segunda búsqueda. El enfoque alternativo 
(el cliente implementa la lógica para determinar si se 
requiere una segunda búsqueda) implicaría un mensaje 
para la primera recuperación de registros, una respues- 
ta a través de la red si no se halla el registro, un segun- 
do mensaje que contuvieralos parámetros de la segunda 
búsqueda, y una respuesta final que contuvierael regis- 
tro recuperado. Si en la segunda búsqueda se necesita el 
50 por 100de las veces, la colocación de la lógica en el 
servidor para evaluar la primera búsqueda e iniciar la 
segunda si fuera necesario reduciría el tráfico de red en 


un 33 por 100. 


Conse) 


Aunque los líneas generoles de lo distribuciónson valiosas, 
todos los sistemas deben de tomarse en consideración 

por sus propios méritos. Poro todos los beneficiosderivados 
de, digamos, un clientepesado, el diseñador debe de luchar 
con un conjuntoparecido de contruriedodes. 


La decisión final acerca de la distribución de com- 
ponentes debería estar basada no solamente en la apli- 
cación individual, sino en la mezcla de aplicaciones que 
esté funcionando en el sistema. Por ejemplo, una insta- 
lación podría contener algunas aplicaciones que requie- 
ran un extenso procesamiento de IGU y muy poco 
procesamiento central de la base de datos. Esto daría 
lugar a la utilización de potentes estaciones de trabajo 
en el lado cliente y a un servidor muy sencillo. Una vez 
implantada esta configuración, otras aplicacionesfavo- 
recerían el enfoque de cliente principal, para que las 
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capacidades del servidor no tuvieran necesidad de ver- 
se aumentadas. 

Habría que tener en cuenta que a medida que madu- 
ra el uso de la arquitectura cliente/servidor, la tenden- 
cia es a ubicar la lógica de la aplicación volátil en el 
servidor. Esto simplifica la implantación de actualiza- 
ciones de software cuando se hacen cambios en la lógi- 
ca de la aplicación [PAU9S]. 


28,9,4, Enlazado de componentes de softwareC/S 


Seutiliza toda una gama de mecanismos distintos para 
enlazar los distintos componentes de la arquitectura 
cliente/servidor. Estos mecanismos están incluidos en 
la estructura de la red y del sistema operativo, y resul- 
tan transparentes para el usuario final situado en el cen- 
tro cliente. Los tipos más comunes de mecanismos de 
enlazado son: 


Tuberías (pipes):se utilizan mucho en los sistemas 
basados en UNIX; las tuberías permiten la mensaje- 
ría entre distintas máquinas que funcionen con dis- 
tintos sistemas operativos. 


Llamadas a procedimientos remotos: permiten que 
un proceso invoque la ejecución de otro proceso o 
módulo que resida en una máquina distinta. 

¿Cuáles son las opciones 


Ed disponibles para vincular 
componentes? 


Interacción SOL clientelservidor: se utiliza para pasar 
solicitudes SQL y datos asociados de un componente 
(típicamente situado en el cliente) a otro componente 
(típicamenteel SGBD del servidor). Este mecanismo 
está limitado únicamente a las aplicaciones SGBDR. 


Conexiones (sockets ),se tratan en la Sección 28.6. 


Además, las implementaciones orientadas a objetos 
de componentes de software C/S dan lugar a una W- 
culación» que haga uso de un distribuidor de solicitu- 
des de objetos. Este enfoque se describirá en la sección 
siguiente. 


28.9.5. Software intermedio (middleware) 
y arquitecturasde agente de solicitud 
de objetos 


Los componentes de software C/S descritos en las sec- 
ciones anteriores están implementadas mediante obje- 
tos que deben de ser capaces de interactuar entre sí en 
el seno de una sola máquina (bien sea cliente o servidor) 
O através de la red. Un agente de distribución de obje- 
tos (ORB) es un componente de softwareintermedio que 
capacita a un objeto que resida en un cliente para enviar 
un mensaje a un método que esté encapsulado en otro 
objeto que resida en un servidor. En esencia, el ORB 
intercepta el mensaje y maneja todas las actividades de 
comunicación y de coordinación necesarias para hallar 
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el objeto al cual se había destinadoel mensaje, para invo- 
car su método, para pasar al objeto los datos adecuados, 
y para transferir los datos resultantes de vuelta al obje- 
to que generase el mensaje inicialmente. 


a 


Un ORB capacito a un objeto que resida en un cliente 
para enviar un mensaje a un método que esté 
encapsulodoen otro objeto que resido en un servidor. 


En el Capítulo 27 se estudiaron los tres estándares 
más utilizados que implementan una filosofía de redis- 
tribución de objetos: CORBA, COM y JavaBeans. COR- 
BA se utilizará para ilustrar la utilización del software 
intermedio ORB. 


Referencia Web 


La información más actualizada sobre estándares de 
componentes se puede encontrar en la página 
www.omg.com, www.microsoft.com/COM, y 
java.sun.com/beans 


En la Figura 28.6 se muestra la estructura básica de 
una arquitecturaCORBA. Cuando se implementaCOR- 
BA en un sistema cliente/servidor, los objetos y las cla- 
ses de objetos (Capítulo 20) tanto en el cliente como en 
el servidor se definen utilizando un lenguaje de des- 
cripción de interfaces (LDÍ), un lenguaje declarativo 
que permite que el ingeniero del software defina obje- 
tos, atributos, métodos y los mensajes que se requieren 
para invocarlos. Con objeto de admitiruna solicitud para 
un método residente en el servidor procedente de un 
objeto residente en el cliente, se crean stubs LDI en el 
cliente y en el servidor. Estos stubs proporcionan la pasa- 
rela a través de la cual se admiten las solicitudesde obje- 
tos a través del sistema C/S. 

Dado que las solicitudes de objetos a través de lared 
se producen en el momento de la ejecución, es preciso 
establecer un mecanismo para almacenar una descrip- 
ción del objeto de tal modo que la información perti- 
nente acerca del objeto y de su ubicación esté disponible 
cuando sea necesario. El repositorio de interfaz hace 
precisamente esto. 


dn poso positivo, pero no 
Jos retos más críticos del 


Cuando una aplicación cliente necesita invocar un 
método contenido en el seno de un objeto residente en 
alguna otra parte del sistema, CORBA utiliza una invo- 


2 En inglés IDL (Interface Description Language) 
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cación dinámica para (1) obtener la información perti- 
nente acerca del objeto deseado a partir del depósito de 
interfaz; (2) crear una estructura de datos con paráme- 
tros que habrá que pasar al objeto; (3) crear una solici- 
tud para el objeto; y (4) invocar la solicitud. A 
continuación, se pasa la solicitud al núcleo ORB —una 
parte dependiente de implementación del sistema ope- 
rativo en red que gestione las solicitudes — y, a conti- 
nuación, se satisface la solicitud. 

La solicitud se pasa a través del núcleo y es proce- 
sada por el servidor. En la ubicación del servidor, un 
adaptador de objetos almacena la información de cla- 
ses y de objetos en un depósito de interfaz residente en 
el servidor, admite y gestiona las solicitudes proce- 


En el Capítulo 2 se presentó un cierto número de 
modelos de proceso de software distintos. Aun cuan- 
do muchos de ellos se podrían adaptar para su utili- 
zación en el desarrollo de software para sistemas C/S, 
hay dos enfoques que son los que se utilizan más 
comúnmente: (1) un paradigma evolutivo que hace 
uso de la ingeniería del software basada en sucesos 
y/o orientada a objetos; y (2) una ingeniería del soft- 
ware basada en componentes (Capítulo 27) que se basa 
en una biblioteca de componentes de software CYD 
y de desarrollo propio. 


Los sistemas cliente servidor se desarrollan emplean- 
do las actividades de ingeniería del software clásicas 
—£l análisis, diseño, construcción y depuración — a 
medida que evoluciona el sistema a partir de un con- 
junto de requisitos de negocios generales para llegar a 
ser una colección de componentes de software ya vali- 
dados que han sido implementados en máquinas clien- 
te y servidor. 


dentes del cliente, y lleva a cabo otras muchas tareas 
de gestión de objetos [ORF99]. En el servidor unos 
stubs LDI, similares a los definidosen la máquina clien- 
te, se emplean como interfaz con la implementación 
del objeto real que reside en la ubicación del servidor. 

El desarrollo del software para sistemas C/S moder- 
nos está orientado a objetos. Empleando la arquitectu- 
ra CORBA descrita brevemente en esta sección, los 
desarrolladores de software pueden crear un entorno en 
el cual se pueden reutilizarlos objetos a lo largo y ancho 
de una red muy amplia. Para más información acerca 
de CORBA y de su impacto general sobre la ingeniería 
del software para sistemas C/S, el lector interesado pue- 


de consultar [HOQ99] y [SIE99]. 


Repositorio 
de interfaz 


dinámica 


Intefaz 
ORB 


de cliente 
de cliente 


ORB 


Repositorio 
de Interfaz 


La actividad de modelado de requisitos para los sistemas 
C/S difiere poco de los métodos de modelado de análisis 
que se aplicaban para la arquitectura de computadoras más 
convencionales. Consiguientemente, los principios bási- 
cos de análisis descritosen el Capítulo 11 y los métodos 
de modelado de análisis presentados en los Capítulos 12 
y 21 son igualmente aplicables al softwareC/S. Se debe- 
ría destacar, sin embargo, que dado que muchos sistemas 
C/S modernos hacen uso de componentes reutilizables, 
también se aplican las actividades de cualificación aso- 
ciadas a la ISBC (Capítulo 27). 


512 


Dado que el modelado de análisis evita la especi- 
ficación de detalles de implementación, sólo cuando 
se haga la transición al diseño se considerarán los 
problemas asociados a la asignación de software al 
cliente y al servidor”. Sin embargo, dado que se apli- 
ca un enfoque evolutivo de la ingeniería del softwa- 
re para los sistemas C/S, las decisiones de imple- 
mentación acerca del enfoque C/S global (por ejem- 
plo, cliente pesado frente a servidor pesado) se podrán 
hacer durante las primeras iteraciones de análisis y 
diseño. 


3 Por ejemplo, una arquitectura C/S conforme a CORBA (Sección 
28.1.5) tendrá un profundo impacto en la decisiones sobre el diseño 
y la implementación. 
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Cuando se está desarrollandoun softwarepara su imple- 
mentación empleando una arquitectura de computado- 
ras concreta, el enfoque de diseño debe de considerar 
el entorno específico de construcción. En esencia, el 
diseño debería de personalizarse para adecuarlo a la 
arquitectura del hardware. 

Cuando se diseña software para su implementación 
empleando una arquitecturacliente/servidor, el enfoque 
de diseño debe de ser «personalizado» para adecuarlo 
alos problemas siguientes: 


* El diseño de datos (Capítulo14) domina el proceso 
de diseño. Para utilizar efectivamente las capacida- 
des de un sistema de gestión de bases de datos rela- 
cional (SGBDR) o un sistema de gestión de bases de 
datos orientado a objetos (SGBDOO) el diseño de 


los datos pasa a ser todavía más significativo que en 
las aplicaciones convencionales. 


Cons) 


Aun cuando el software (/S es diferente, se pueden 
utilizar métodos convencionales o de diseño0O con muy 
pocos modificaciones. 


Cuando se selecciona el paradigma controlado por 
sucesos, debería realizarse el modelado del com- 
portamiento (una actividad del análisis, Capítulo 12 
y 21) y será preciso traducir los aspectos orientados 
al control implícitos en el modelo de comportamiento 
al modelo de diseño. 

El componente de interacción/presentación del usua- 
rio de un sistema C/S implementatodas aquellas fun- 
ciones que se asocian típicamente con una interfaz 
gráfica de usuario (IGU). Consiguientemente,se verá 
incrementada la importancia del diseño de interfa- 
ces (Capítulo 15). El componente de interacción/pre- 
sentación del usuario implementatodas las funciones 
que se asocian típicamente con una interfaz gráfica 
de usuario (1GU). 

Suele seleccionarse un punto de vista orientado a 
objetos para el diseño (Capítulo 22). En lugar de la 
estructura secuencial que proporciona un lenguaje 
de procedimientos se proporciona una estructura de 
objetos mediante la vinculación entre los sucesos 
iniciados en la IGU y una función de gestión de 
sucesos que reside en el software basado en el 
cliente. 


Aun cuando prosigue todavía el debate acerca del 
mejor enfoque de análisis y diseño para los sistemas 
C/S, los métodos orientados a objetos (Capítulos 21 y 
22) parecen ofrecer la mejor combinación de caracte- 
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rísticas. Sinembargo, también se pueden adoptar méto- 
dos convencionales (Capítulos 12 y 16). 


28.12.1. Diseño arquitectónico para sistemas 
cliente/servidor 


El diseño arquitectónico de un sistema cliente servidor 
se suele caracterizar como un estilo de comunicación 
de procesos. Bass y sus colegas [BAS98] describe esta 
arquitecturá de la siguiente manera: 


El objetivo es lograr la calidad de la escalabilidad. Un ser- 
vidor existe para proporcionar datos para uno o más clientes, 
a 

, ja síncronamente o asíncro 
namente, para servir a la solicitud del cliente. Si el servidor 
funciona síncronamente, devuelve el control al cliente al mis- 
mo tiempo que devuelve los datos. Si el servidor trabaja asín- 
cronamente, devuelve solo los datos al cliente (el que tiene su 
propio hilo de control). 


Enel Capítulo 14 se presenta un estudio detallado de 
arquitecturos, 


Dado que los sistemas modernos C/S están basados 
en componentes, se utiliza una arquitectura de agente 
de solicitud de objetos (ORB) para implementar esta 
comunicación síncrona y asíncrona. 

A un nivel arquitectónico, el lenguaje de descrip- 
ción de la interfaz CORBA? se utiliza para especifi- 
car los detalles de la interfaz. La utilización de LDI 
permite que los componentes de software de lá apli- 
cación accedan a los servicios ORB (componentes) 
sin un conocimiento de su funcionamiento interno. 
El ORB también tiene la responsabilidad de coordi- 
nar la comunicación entre los componentes del clien- 
te y del servidor. Para lograr esto, el diseñador 
especifica un adaptador de objetos (también llamado 
encubridor)que proporciona los servicios siguientes 
[BAS98]: 

Se registran las implementaciones de componentes 
(objetos). 

Se interpretan y se reconcilian todas las referencias 
de componentes (objetos). 


Se hacen coincidir las referencias de componentes 
(objetos) con la implementación de los componen- 
tes correspondiente. 

Se activan y desactivan objetos. 

Se invocan métodos cuando se transmiten mensa- 
jes. 

Se implementan servicios de seguridad. 


4 En COM y JavaBeans se utiliza un método análogo. 
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Para adnitir los componentes CY Dproporcionados por 
proveedores diferentes y componentes de desarrollo pro- 
pio que pueden haber sido implementadosutilizando dife- 
rentes tecnologías, se debe diseñar la arquitectura ORB 
para lograr interoperabilidad entres componentes. Para 
poderlo llevar a cabo CORBA utiliza un concepto puente. 

Supongamos que un cliente se haya implementado 
utilizando un protocolo ORBX y que el servidor se haya 
implementado utilizando el protocolo ORB Y. Ambos 
protocolos son conforme CORBA, pero debido a las 
diferencias de implementacióninternas, se deben comu- 
nicar con un «puente» que proporcione un mecanismo 
para la traducción entre protocolos internos [BAS98]. 
El puente traduce mensajes de manera que el cliente y 
el servidor se puedan comunicar suavemente. 


28.12.2. Enfoques de diseño convencionales para 
software de aplicaciones 


En los sistemas cliente/servidor, los diagramas de flujo 
(Capítulos 12 y 14) se pueden utilizar para establecer 
el ámbito del sistema, para identificar las funciones de 
nivel superior y las áreas de datos temáticas (almace- 
nes de datos), y para permitir la descomposición de fun- 
ciones de nivel superior. Apartándose del enfoque DFD 
tradicional, sin embargo, la descomposición se detiene 
en el nivel de un proceso de negocio elemental, en lugar 
de proseguir hasta el nivel de procesos atómicos. 

En el contexto C/S, se puede definir un proceso ele- 
mental de negocios (PEN) como un cierto conjunto de 
tareas que se llevan a cabo sin interrupción por parte 
de un usuario en los centros cliente. Estas tareas O bien 
se realizan en su totalidad, o bien no se realizan en 
absoluto. 

El diagrama entidad relación adopta también un 
papel más importante. Sigue utilizándose para des- 
componer las áreas de datos temáticas (de almacenes 
de datos) de los DFD con objeto de establecer una 
visión de alto nivel de la base de datos que haya que 
implementar empleando un SGBDR. Su nuevo papel 
consiste en proporcionar la estructura para definir obje- 
tos de negocios de alto nivel (Sección 28.4.3). 

En lugar de servir como herramientas para una des- 
composición funcional, el diagrama de estructuras se 
utiliza ahora como diagrama de ensamblaje, con obje- 
to de mostrar los componentes implicados en la solu- 
ción de algún procedimiento de negocios elemental. 
Estos componentes, que constan de objetos de inter- 
faz, objetos de aplicación y objetos de bases de datos, 
establecen la forma en la que se van a procesar los 
datos. 


28.12.3. Diseño de bases de datos 


El diseño de bases de datos se utiliza para definir y 
después para especificar la estructura de los objetos 
de negocios que se emplean en el sistema cliente/ser- 
vidor. El análisis necesario para identificar los obje- 


tos de negocios se lleva a cabo empleando los méto- 
dos de ingeniería de la información descritos en el 
Capítulo 10. La notación de modelado del análisis 
convencional (Capítulo 12), tal como DER, se podrá 
utilizar para definir objetos de negocios, pero es pre- 
ciso establecer un depósito de base de datos para cap- 
turar la información adicional que no se puede 
documentar por completo empleando una notación 
gráfica tal como un DER. 

En este depósito, se define un objeto de negocio como 
una información que es visible para los compradores y 
usuarios del sistema, pero no para quienes lo imple- 
mentan, por ejemplo, un libro en el caso de estudio de 
ventas de libros. Esta información que se implementa 
utilizando una base de datos relacional, se puede man- 
tener en un depósito de diseño. La siguiente informa- 
ción de diseño se recoge para la base de datos 
cliente/servidor [POR94]: 


» Entidades: se identifican en el DER del nuevo sis- 
tema. 


» Archivos: que implementan las entidades identifica- 
das en el DER. 


» Relación entre campo y archivo: establece la dispo- 
sición de los archivos al identificar los campos que 
están incluidos en cada archivo. 


. Campos: define los campos del diseño (el dicciona- 
rio de datos). 


» Relaciones entre archivos: identifican los archivos 
relacionados que se pueden unir para crear vistas 
lógicas o consultas. 


» Validación de relaciones: identifica el tipo de rela- 
ciones entre archivos o entre archivos y campos que 
se utilicen par la validación. 


» Tipos de campo: se utiliza para permitir la herencia 
de característicasde campos procedentes de superen- 
laces del campo (por ejemplo, fecha, texto, número, 
valor, precio). 


»  Tipode datos: las características de los datos conte- 
nidos en el campo. 


»  Tipode archivo: se utiliza para identificarcualquiera 
de las ubicaciones del archivo. 


* Función del campo: clave, clave externa, atributo, 
campo virtual, campo derivado, etc. 


»  Valorespermitidos: identificalos valores permitidos 
para los campos de tipo de estado. 


» Reglas de negocios: reglas para editar, calcular cam- 
pos derivados, etc. 


datos en uno base de datos 
el significado subyacente y la 
s de forma eficoz y correcto. 
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A medida que las arquitecturas C/S se han ido hacien- 
do más frecuentes, la tendencia hacia una gestión de 
datos distribuida se ha visto acelerada. En los sistemas 
C/S que implementan este enfoque, el componente de 
gestión de datos reside tanto en el cliente como en el ser- 
vidor. En el contexto del diseño de bases de datos, un 
problema fundamental es la distribución de datos. Esto 
es, ¡cómo se distribuyen los datos entre el cliente y el 
servidor y cómo se dispersan entre los nudos de la red? 

Un sistema de gestión de bases de datos relacional 
(SGBDR)hace fácilel acceso a datos distribuidos median- 
te el uso del lenguaje de consulta estructurado(SQL). La 
ventaja de SQLen una estructuraC/S es que «no requie- 
re navegar» [BER92]. En un SGBDR, los tipos de datos 
seespecificanempleando SQL, pero no se requiere infor- 
mación de navegación. Por supuesto, la implicación de 
esto es que SGBDR debe ser suficientemente sofisticado 
para mantener la ubicación de todos los datos y tiene que 
ser capaz de definir la mejor ruta hasta ella. En sistemas 
de bases de datos menos sofisticados, una solicitud de 
datos debe indicar a qué hay que acceder y dónde se 
encuentra. Si el software de aplicación debe mantener la 
información de navegación, entonces la gestión de datos 
se vuelve mucho más complicada por los sistemas C/S. 

¿Qué opciones existen para 


2 distribuir datos dentro de un 
sistema C/5? 


Es preciso tener en cuenta que también están dispo- 
nibles para el diseñador [BER92] otras técnicas para la 
distribución y gestión de datos: 


Extracción manual. Se permite al usuario copiar 
manualmente los datos adecuados de un servidor a un 
cliente. Este enfoque resulta útil cuando el usuario 
requiere unos datos estáticos y cuando se puede dejar 
el control de la estación en manos del usuario. 

Instantánea. Esta técnica automatiza la extracción 
manual al especificar una «instantánea»de los datos que 
deberán de transferirse desde un cliente hasta un servi- 
dor a intervalos predefinidos. Este enfoque es Útil para 
distribuir unos datos relativamente estáticos que sola- 
mente requieran actualizaciones infrecuentes. 


Duplicación. Se puede utilizar esta técnica cuando 
es preciso mantener múltiples copias de los datos en dis- 
tintos lugares (por ejemplo, servidores distintos o clien- 
tes y servidores). En este caso, el nivel de complejidad 
se incrementa porque la consistencia de los datos, las 
actualizaciones,la seguridad y el procesamiento deben 
de coordinarse entre los múltiples lugares. 


Fragmentación. En este enfoque, la base de datos 
del sistema se fragmenta entre múltiples máquinas. Aun- 
que resulta intrigante en teoría, la fragmentación es 
excepcionalmente difícil de implementar y hasta el 
momento no es frecuente encontrarla. 

El diseño de bases de datos, y más específicamente, 
el diseño de bases de datos para sistemas C/S son temas 
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que van más allá del alcance de este libro. El lector inte- 
resado puede consultar [BRO91], [BER92], [VAS93] y 
[ORF99] para una descripción más extensa. 


Objetos de 
interfaz 
(Componentes) 


Asociación 


de des 9 


Objetos de 
base de datos 
(Componentes) 


Asociación 
ode contro! 


Objetos 
de aplicación 
(Componentes) 


FIGURA 28.7. Notación de diagrama de estructura 
para componentes C/S. 


..., 


28.12.4. Visión general de un enfoque de diseño 


Porter [POR95] sugiere un conjunto de pasos para dise- 
ñar un proceso elemental de negocio que combine ele- 
mentos de diseño convencional con elementos de 
diseño orientado a objetos. Se supone que se ha desa- 
rrollado un modelo de requisitos que defina los obje- 
tos de negocio, y que se ha refinado ya antes de 
comenzar el diseño de los procesos elementales de 
negocio. Entonces, se utilizan los pasos siguientes para 
derivar el diseño: 


1. Para cada proceso elemental de negocio, se identifi- 
can los archivos creados, actualizados, borrados o 


referenciados 


. Se utilizan los archivos identificados en el paso 1 
como base para definir componentes u objetos. 


. Para cada componente, se recuperan las reglas de 
negocio y otra información de objetos de negocio 
que se haya determinado para el archivo relevante. 


Se determinan las reglas que son relevantes para el 
proceso y se descomponen las reglas hasta llegar al 
nivel de métodos. 


. Según sea necesario, se definen los componentes 
adicionales que se requieren para implementar los 
métodos. 


Porter [POR95] sugiere una notación especializada 
de diagramas de estructura (Fig. 28.7) para representar 
la estructura de componentes de un proceso elemental 
de negocio. Sinembargo, se utiliza una simbología dife- 
rente para que el diagrama se ajuste a la naturaleza orien- 
tada a objetos del software C/S. En la figura, se 
encuentran cinco símbolos distintos: 


Objeto de interfaz. Este tipo de componente, que 
también se denomina componente de interacción/pre- 
sentación con el usuario, se construye típicamente en 
un único archivo O bien otros archivos relacionados que 
se hayan unido mediante una consulta. Incluye méto- 
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dos para dar formato a la interfaz IGU y también la 
lógica de aplicación residente en el cliente, junto con 
los controles de la interfaz. También incluye sentencias 
incrustadas de SQL, que especifican el procesamiento 
de la base de datos efectuado en el archivo primario con 
respecto al cual se haya construido la interfaz. Si la 
lógica de aplicación asociada normalmente a un objeto 
de interfaz se implementa en un servidor, típicamente 
mediante el uso de herramientas de software interme- 
dio, entonces la lógica de aplicación que funcione en el 
servidor deberá de identificarsecomo un objeto de apli- 
cación por separado. 


Objeto de base de datos. Este tipo de componentes 
se utiliza para identificar el procesamiento de bases de 
datos tal como la creación o selección de registros que 
esté basada en un archivo distinto del archivo primario 
en el cual se haya construido el objeto de interfaz. Es 
preciso tener en cuenta que si el archivo primario con 
respecto al cual se construyeel objeto de interfaz se pro- 
cesa de manera distinta, entonces se puede utilizar un 
segundo conjunto de sentencias SQL para recuperar un 
archivo en una secuencia alternativa. La técnica de pro- 
cesamiento del segundo archivo debería identificarse 
por separado en el diagrama de estructura, en forma de 
un objeto de base de datos por separado. 


Objeto de aplicación. Es utilizado por un objeto de 
interfaz, bien por un objeto de base de datos, y este com- 
ponente será invocado bien por un activadorde una base 
de datos, o por una llamada a procedimientos remotos. 
También se puede emplear para identificar la lógica de 
negocios que normalmente se asocia al procesamiento 
de interfaz que ha sido trasladado al servidor para su 
funcionamiento. 


Asociación de datos. Cuando un objeto invoca a otro 
objeto independiente, se pasa un mensaje entre dos obje- 
tos. El símbolo de asociación de datos se utiliza para 
denotar este hecho. 

Asociación de control. Cuando un objeto invoca a 
otro objeto independiente y no se pasan entre los dos 
objetos, se utiliza un símbolo de asociación de control. 


28.12.5. Iteración del diseño de procesos 

El repositorio de diseño (Sección 28.4.3), que se utili- 
za para representar objetos de negocio, se emplea tam- 
bién para representar objetos de interfaz, de aplicación 
y de base de datos. Obsérvese que se han identificado 
las entidades siguientes: 

Métodos: describen cómo hay que implementar una 
regla de negocio. 

Procesos elementales: definen los procesos elementa- 
les de negocio identificadosen el modelo de análisis. 

Enlace procesolcomponente: identifica a los com- 
ponentes que forman la solución de un proceso ele- 
mental de negocio. 

Componentes: describe los componentes mostrados 
en el diagrama de estructura. 

Enlace regla de negocioslcornponente: identifican a 
los componentes que son significativos para la imple- 
mentación de una determinada regla de negocio. 


Si se implementa un repositorio utilizando un 
SGBDR, el diseñador tendrá acceso a una herramienta 
de diseño muy Útil que proporciona informes que sir- 
ven de ayuda tanto para la construcción como para el 
futuro mantenimiento del sistema C/S. 


La naturaleza distribuida de los sistemas cliente/ser- 
vidor plantea un conjunto de problemas específicospara 
los probadores de software. Binder [BIN92] sugiere las 
siguientes zonas de interés: 


Consideraciones del IGU de cliente. 


Consideraciones del entorno destino y de la diversi- 
dad de plataformas. 


Consideraciones de bases de datos distribuidas (inclu- 
yendo datos duplicados). 


Consideraciones de procesamiento distribuido (inclu- 
yendo procesos duplicados). 


Entornos destino que no son robustos. 
Relaciones de rendimiento no lineales. 


5 Esta sección es una versión muy abreviada y adaptada de un ar- 
tículo escrito por Daniel Mosley [MOS96] (utilizado con permiso del 
autor). En [MOS99] se puede encontrar una versión actualizada y 
ampliada. 
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Referencia Web 


Se presentan recursos e información Útil 
sobre comprobaciones C/S en lo dirección 
www.icon-stl.net / -d¡mosley / 


La estrategia y las tácticas asociadas a la comproba- 

0 o ermita 
ción C/S deben diseñarse de tal mado que se P* 

al El todos y cada uno de los do anteriores. 


28.13.1. Estrategia general de pruebas C/S 


En general, las pruebas de software cliente/servidor se 
produce en tres niveles diferentes: (1) las aplicaciones 
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de cliente individuales se prueban de modo «desconec- 
tado» (el funcionamiento del servidor y de la red sub- 
yacente no se consideran); (2) las aplicaciones de 
software de cliente y del servidor asociado se prueban 
al unísono, pero no se ejercitan específicamentelas ope- 
raciones de red; (3)se prueba la arquitectura completa 
de C/S, incluyendo el rendimiento y funcionamiento de 
la red. 

Aun cuando se efectúen muchas clases distintas de 
pruebas en cada uno de los niveles de detalle anterio- 
res, es frecuente encontrar los siguientes enfoques de 
pruebas para aplicaciones C/S: 


Pruebas defunción de aplicación. Se prueba la fun- 
cionalidad de las aplicaciones cliente utilizando los 
métodos descritos en el Capítulo 17. En esencia, la apli- 
cación se prueba en solitario en un intento de descubrir 
errores de su funcionamiento. 

¿Qué tipos de 


$ comprobaciones se realizan 
para los sistemas (/$? 


Pruebas de servidor. Se prueban la coordinación y 
las funciones de gestión de datos del servidor. También 
se considera el rendimiento del servidor (tiempo de res- 
puesta y trasvase de datos en general). 


Pruebas de bases de datos. Se prueba la precisión e 
integridad de los datos almacenados en el servidor. Se 
examinan las transacciones enviadas por las aplicacio- 
nes cliente para asegurar que los datos se almacenen, 
actualicen y recuperen adecuadamente. También se 
prueba el archivado. 


Pruebas de transacciones. Se crea una serie de prue- 
bas adecuada para comprobar que todas las clases de tran- 
sacciones se procesen de acuerdo con los requisitos. Las 
transacciones hacen especial hincapié en la corrección 
de procesamiento y también en los temas de rendimiento 
(por ejemplo, tiempo de procesamiento de transacciones 
y comprobación de volúmenes de transacciones). 


Pruebas de comunicaciones a través de la red. Estas 
pruebas verifican que la comunicación entre los nudos 
de la red se produzca correctamente, y que el paso de 
mensaje, las transacciones y el tráfico de red relacio- 
nado tenga lugar sin errores. También se pueden efec- 
tuar pruebas de seguridad de la red como parte de esta 
actividad de prueba. 


Para llevar a cabo estos enfoques de pruebas, Musa 
[MUS93] recomienda el desarrollo de perfiles operati- 
vos derivados de escenarios cliente/servidor. Un perfil 
operativo indica la forma en que los distintos tipos de 
usuarios interactúancon el sistemaC/S. Esto es, los per- 
files proporcionan un «patrón de uso» que se puede apli- 
car cuando se diseñan y ejecutan las pruebas. Por 
ejemplo, para un determinado tipo de usuarios, ¿qué 
porcentaje de las transacciones serán consultas? ¿Actua- 
lizaciones? ¿Pedidos? 
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las técnicos de elictución de requisitos y los cosos 
prácticos de estudio se traton en el Capítulo 11, 


Para desarrollar el perfil operativo, es preciso deri- 
var un conjunto de escenarios de usuario [BIN9S], que 
sea similar a los casos prácticos de estudio tratados en 
este libro. Cada escenario abarca quién, dónde, qué y 
por qué. Esto es, quién es el usuario, dónde (en la arqui- 
tectura física) se produce la interacción con el sistema, 
cuál es la transacción, y por qué ha sucedido. Se pue- 
den derivar los escenarios durante las técnicas de obten- 
ción de requisitos O a través de discusiones menos 
formales con los usuarios finales. Sin embargo, el resul- 
tado debería ser el mismo. Cada escenario debe pro- 
porcionar una indicación de las funciones del sistema 
que se necesitarán para dar servicio a un usuario con- 
creto; el orden en que serán necesarias esas funciones, 
los tiempos y respuestas que se esperan, y la frecuen- 
cia con la que se utilizará cada una de estas funciones. 
Entonces se combinan estos datos (para todos los usua- 
rios) para crear el perfil operativo. 

La estrategia para probar arquitecturas C/S es aná- 
loga a la estrategia de pruebas para sistemas basados en 
software que se describían en el Capítulo 18. La com- 
probación comienza por comprobar al por menor. Esto 
es, se comprueba una única aplicación de cliente. La 
integración de los clientes, del servidor y de la red se 
irá probando progresivamente. Finalmente, se prueba 
todo el sistema como entidad operativa. La prueba tra- 
dicional visualiza la integración de módulos para sub- 
sistemas/sistemas y su prueba (Capítulo 18) como un 
proceso descendente, ascendente o alguna variación de 
los dos anteriores. La integración de módulos en el desa- 
rrollo C/S puede tener algunos aspectos ascendentes o 
descendentes, pero la integración en proyectos C/S tien- 
de más hacia el desarrollo paralelo y hacia la integra- 
ción de módulos en todos los niveles de diseño. Por 
tanto, la prueba de integraciónen proyectos C/S se efec- 
túa a veces del mejor modo posible empleandouna apro- 
ximación no incremental o del tipo «big bang». 


es Un área 
se encuentran 
les y los sistemas 


El hecho de que el sistema no se esté construyendo 
para utilizar un hardware y un software especificado 
con anterioridad tiene su impacto sobre la comproba- 
ción del sistema. La naturaleza multiplataforma en red 
de los sistemas C/S requiere que se preste bastante más 
atención a la prueba de configuraciones y a la prueba 
de compatibilidades. 
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INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRÁCTICO 


La doctrina de prueba de configuraciones impone la 
prueba del sistema en todos los entornos conocidos de 
hardware y software en los cuales vaya a funcionar. La 
prueba de compatibilidad asegura una interfaz funcio- 
nalmente consistente entre plataformas de software y 
hardware. Por ejemplo, la interfaz de ventanas puede ser 
visualmente distinta dependiendo del entorno de imple- 
mentación, pero los mismos comportamientos básicos 
del usuario deberían dar lugar a los mismos resultados 
independientementedel estándar de interfaz de cliente. 


Especificación de pruebas (/S 


28.13.2, Táctica de pruebas C/S 


Aun cuando el sistema C/S no se haya implementado 
empleando tecnología orientada a objetos, las técni- 
cas de pruebas orientadas a objetos (Capítulo 23) tie- 
nen sentido porque los datos y procesos duplicados se 
pueden organizar en clases de objetos que compartan 
un mismo conjunto de propiedades. Una vez que se 
hayan derivado los casos prácticos para una clase de 
objetos (o su equivalente en un sistema desarrollado 
convencionalmente), estos casos de prueba deberían 
resultar aplicables en general a todas las instancias de 
esa clase. 

El punto de vista OO es especialmente valioso cuan- 
do se considera la interfaz gráfica de usuario de los 
sistemas C/S modernos. La IGU es inherentemente 
orientada a objetos, y se aparta de las interfaces tradi- 
cionales porque tiene que funcionar en muchas plata- 


formas. Además, la comprobación debe explorar un 
elevado número de rutas lógicas, porque la IGU crea, 
manipula y modifica una amplia gama de objetos grá- 
ficos. La comprobación se ve complicada aun más por- 
que los objetos pueden estar presentes O ausentes, 
pueden existir durante un cierto período de tiempo, y 
pueden aparecer en cualquier lugar del escritorio. 


Esto significa que el enfoque tradicional de captu- 
ra/reproducción para comprobar interfaces convencio- 
nales basadas en caracteres debe ser modificado para 
que pueda manejar las complejidades de un entorno 
IGU. Ha aparecido una variación funcional del para- 
digma de captura/reproducción denominado captura! 
reproducción estructurada [FAR93] para efectuar la 
prueba de la IGU. 


La captura/reproducción tradicional registra las 
entradas tales como las teclas pulsadas y las salidas 
tales como imágenes de pantalla que se almacenan 
para comprobaciones posteriores. La captura/repro- 
ducción estructurada está basada en una visión in- 
terna (lógica) de las actividades externas. Las 
interacciones del programa de aplicación con la IGU 
se registran como sucesos internos, que se pueden 
almacenar en forma de «guiones» escritos en Visual 
Basic de Microsoft, en una de las variantes de C, o 
en el lenguaje patentado del fabricante. Las herra- 
mientas que ejercitan las IGUs no abarcan las vali- 
daciones de datos tradicionales ni tampoco las 
necesidades de comprobación de rutas. Los métodos 
de comprobación de caja blanca: y caja negra descri- 
tos en el Capítulo 17 son aplicables en muchos casos, 
y las estrategias orientadas a objetos especiales que 
se presentaban en el Capítulo 23 son adecuadas tan- 
to para el software de cliente como para el software 
de servidor. 


Aun cuando los sistemas cliente/servidor pueden adop- 
tar uno o más de los modelos de procesos de software 
y muchos de los métodos de análisis, diseño y com- 
probación descritos anteriormente en este libro, las 
característicasde arquitecturas especiales de C/S requie- 
ren una personalización del software de ingeniería del 
software. En general, el modelo de proceso del software 
que se aplicaa los sistemasC/S tiene una naturalezaevo- 
lutiva, y los métodos técnicos suelen tender a enfoques 
orientadosa objetos. El desarrolladordebe describir aque- 
llos objetos que se produzcan en la implementación de los 
componentes de interacción representación con el usua- 
rio, de base de datos y de aplicación. Los objetos defi- 
nidos para estos componentes deberían asignarse bien 
a la máquina, o bien a la máquina servidor, y se pue- 
den vincular a través de un distribuidor de solicitudes 
de objetos. 
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Las arquitecturas de agente de solicitud de objetos 
sirven de apoyo para los diseños C/S en los cuales los 
objetos cliente envían mensajes a los objetos servidor. 
El estándar CORBA hace uso de un lenguaje de defini- 
ción de interfaz, y los repositorios de interfaz gestionan 
las solicitudes de objetos independientemente de su ubi- 
cación dentro de la red. 

El análisis y el diseño de sistemas cliente/servidor 
hacen uso de diagramas de flujo de datos y de enti- 
dades y relaciones, diagramas de estructura modifi- 
cados, y otras notaciones que se encuentran en el 
desarrollo de aplicaciones convencionales. Es preci- 
so modificar las estrategias de comprobación para ade- 
cuarlas a las comprobaciones que examinan la 
comunicación a través de la red y el juego entre el 
software que reside en el cliente y aquel que reside en 
el servidor. 
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CAPITULO 28 INGENIERIA DEL SUFI WAKE DEL CUMEKCIU ELECTRÓNICO CLIENTE/SERVIDOR 


[BAS98] Bass, L., P. Clemens y R. Kazman, Software Archi- 
tecture in Practice, Addison-Wesley, 1998. 


[BER92] Berson, A., ClientlServer Architecture, McGraw- 
Hill, 1992. 
[BIN92] Binder,R., «A CASE-based Systems Engineering 


Approach to Client-Server Development», CASE Trends, 
1992. 


[BIN95] Binder,R., «Scenario-Based Testing for Client Ser- 
ver systems», Software Development, vol. 3, n.? 8, Agos- 
to de 1995, pp. 43-49. 

[BRO91] Brown, A.W., Object- Oriented Databases, 
McGraw-Hill, 1991. 


[FAR93] Farley, K.J., «Software Testing For Windows Deve- 
lopers», Data Based Advisor, Noviembre de 1993, pp. 45- 
46, 50-52, 

[HOQ99] Hoque, R., CORBAfor Real Programmers, Áca- 
demic Press/Morgan Kaufmann, 1999. 


[MOS99] Mosley, D., Client Server Software Testing on the 
Desk Top and the Web, Prentice-Hall, 1999, 

[MUS93] Musa, J., «Operational Profilesin Software Relia- 
bility Engineering», IEEE Software, Marzo de 1993, pp. 
14-32. 

[ORF991] Orfali, R., D, Harkey y J. Edwards, Essential 
ClientlServer Survival Guide, 3.2 ed., Wiley, 1999. 

[PAU95] L, G. Paul, «Client/Server Deployment», Compu- 
terworld, 18de Diciembre, 1995. 

[POR94] Porter, J., O-DES Design Manual, Fairfield Uni- 
versity, 1994, 

[POR95] Porter, J., Synon Developer's Guide, McGraw-Hill, 
1995. 

[REE97] Reece, G., JBDC and Java, O'Reilly, 1997, 

[SIE99] Siegel, J., CORBA 3 Fundamentals and Program- 
ming, Wiley, 1999. 

[VAS93] Vaskevitch, D., ClientlServer Strategies, IDG 
Books. 1993. 


28.1. Empleando publicaciones comerciales o recursos e Inter- 
net de información de fondo, defina un conjunto de criterios 
para evaluar herramientas para la ingeniena del software C/S. 


28.2. Sugieracinco aplicacionesen las cuales un servidorpesa- 
do parezca una estrategia de diseño adecuada. 


28.3. Sugieracinco aplicacionesen las cuales un cliente pesa- 
do parezca ser una estrategia de diseño adecuada. 


28.4. Efectúe una investigaciónsobre los Últimos delitos come- 
tidos en Intemet y describa cómo la tecnología de seguridad 
apuntada en este capítulo podría haberla evitado. 


28.5. Describa cómo se podría estructurarun sistema de reser- 
vas en unas líneas aéreas como un sistema cliente/servidor. 


28.6. Investigue los últimos avances en software para traba- 
jo en grupo y desarrolle una breve presentación para la clase. 
El profesor puede asignar una función específica a los distin- 
tos participantes. 


28.7. Una compañía va a establecer una nueva división de 
ventas por catálogo para vender mercancías de uso frecuente 
y en exteriores. El catálogo electrónico se publicaráen la World 


Wide Web, y se pueden hacer pedidos a través de correo elec- 
trónico, mediante el sitio Web y también por teléfono o fax. 
Se construirá un sistema cliente/servidor para prestar su apo- 
yo al procesamiento de pedidos en el sitio de la compañía. 
Defina un conjunto de objetos de alto nivel que fueran nece- 
sarios para el sistema de procesamiento de pedidos, y organi- 
ce estos objetos en tres categorías de componentes: la 
presentación con el usuario, la base de datos y la aplicación. 


28.8. Formulereglas de negocio para establecercuándose pue- 
de efectuar un envío si el pago se efectúa mediante tarjeta de 
crédito, con respecto al sistema descrito en el Problema 28.7. 
Añada reglas adicionales si el pago se efectúamediante cheque. 


28.9. Desarrolle un diagrama de transición de estados (Capí- 
tulo 12)que defina los sucesos y estados que resultarían visi- 
bles para un dependiente de entrada de pedidos que trabajase 
en un PC cliente en la división de ventas por catálogo (Pro- 
blema 28.7). 


28.10. Ofrezca ejemplos de tres o cuatro mensajes que pudie- 
ran dar lugar a una solicitud de un método de cliente mante- 
nido en el servidor. 


Aun cuando los métodos básicos de análisis y diseño para 
sistemas cliente/servidor son bastante parecidos a los siste- 
mas OO convencionales, se requieren técnicas y conoci- 
mientos especializados. Lowe y Helda han escrito unas 
introducciones valiosas a los conceptos básicos (ClientíSer- 
ver Computingfor Dummies, 3.2 ed., IDG Books Worldwide, 
1999), al igual que Zantinge y Adriaans (Managing Client/Ser- 
ver, Addison"Wesley, 1997). En un nivel intermedio, McCla- 
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nahan (Developing Client-Server Applications, IDG Books 
Worldwide, 1999) abarca un amplio abanico de temas C/S. 
A un nivel más sofisticado, Orfali y sus colaboradores 
[ORF99], y Linthicum (Guide to Clientl Server and Intranet 
Development, Wiley, 1997) proporcionan las líneas genera- 
les detalladas para aplicaciones C/S. Berson (ClientlServer 
Architecture, 2.2 ed., McGraw-Hill, 1996)trata temas de arqui- 
tectura y componentes. 
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En los últimos años las computadorasde redes se han con- 
vertidoen un tema tecnológicocandente (y una estrategiaarries- 
gada de negocios). Sinclair y Merkow (Thin Clients Clearly 
Explained, Morgan Kaufmann Publishers, 1999), Friedrichs y 
Jubin (Java Thin-Client Programrningfor a Network Compu- 
ting Environment, Prentice-Hall,1999), Dewire (Thin Clients, 
McGraw-Hill, 1998) y Kanter(UnderstandingThin-Client/Ser- 
ver Cornputing, Microsoft Press, 1998)proporcionan una guía 
valiosa de cómo diseñar, construir, hacer uso y apoyar siste- 
mas cliente ligeros (delgados). 

Empezando con el modelado de sucesos de negocios, 
Ruble (PracticalAnalysis and Designfor ClientlServer and 
GUI Systems, 1997) proporciona un estudio en profundidad 
de las técnicas para el análisis y diseño de sistemas C/S. Los 
libros de Goldman, Rawles y Mariga (ClientlServer Infor- 
mation Systems: A Business-Oriented Approuch, Wiley, 1999), 
Shan, Earle y Lenzi (Enterprise Computing With Objects: 
From ClientlServer Environments to the Internet, Addison- 
Wesley, 1997) y Gold-Berstein y Marca (Designing Enter- 
prise ClientlServer Systems, Prentice-Hall, 1997) tienen en 
consideración los sistemas C/S en un contexto más amplio 
de empresa. 

Existe un grupo de libros que estudian la seguridad en 
redes; a continuación se proporciona una muestra: 

Stallings, W., Cryptology and Network Security, Prenti- 
ce-Hall, 1998. 

Gralla, P., The Complete Idiots Guide to Protecting Your- 
self Online, Que, 1999. 

Ghosh, A. K., E-cornrnerce Security: Weak Links, Best 
Defenses, John Wiley, 1998. 

Atkins, D. T., Shelden y T. Petru, Internet Security: Pro- 

fessional Reference, New Riders Publishing, 1997. 

Bernstein, T., A.B. Bhimani, E. Schultz y C. Siegel, Inter- 
net Securityfor Business, John Wiley, 1998. 

Garfinkel, S., y G. Spafford, Web Security and Commer- 
ce, O. Reilly, 1997. 

Tiwana, A., Web Security, Digital Press, 1999, 


Loosely y Douglas (High-Performance ClientlServer, 
Wiley, 1997) explican los principios de la ingeniería de ren- 
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dimiento del software y los aplican a la arquitectura y al dise- 
ño de los sistemas distribuidos. Heinckiens y Loomies (Buil- 
ding Scalable Database Applications: Object-Oriented 
Design, Architectures, and Implementations, Addison-Wes- 
ley, 1998) dan importancia al diseño de bases de datos en su 
guía para construir aplicaciones cliente/servidor. Ligon 
(ClientlServer Comrnunicutions Services: A Guidefor the 
Applications Developer, McGraw-Hill, 1997) tiene en cuen- 
tauna gran variedad de temas de comunicación relacionados 
entre los que se incluyen TCP/IP, ATM, EDI, CORBA, men- 
sajes y encriptación. Schneberger (ClientlServer Software 
Maintenance, McGraw-Hill, 1997) presenta un marco de tra- 
bajo para controlar los costes de mantenimiento de software 
C/S y para optimizar el apoyo al usuario. 

Literalmente cientos de libros abarcan el desarrollo de sis- 
temas C/S específicos del vendedor. La siguiente relación 
representa un pequeño muestreo: 


Anderson, G.W., Client/Server Database Design With 
Sybase: A High-Performance and Fine-Tuning Guide, 
McGraw-Hill, 1997. 

Barlotta, M. J., Distributed Application Development With 
Powerbuilder 6, Manning Publications Company, 1998. 

Bates, R.J., Hands-On Client/Server Internetworking, 
McGraw-Hill, 1997. 

Mahmoud, Q.H., Distributed Programming with java, 
Manning Publications Company, 1998. 

Orfali, R., y Harkey, Client/Server Programming with 
JavaBeans, Wiley, 1999, 

Sankar, K., Building Internet Client/Server Systems, 
McGraw-Hill, 1999, 


Mosley [MOS99] y Boume (Testing ClientlServer Sys- 
terns, McGraw-Hill, 1997) han escrito libros de guía detalla- 
dos para pruebas C/S. Ambos autores proporcionanun estudio 
en profundidad de las estrategias de comprobación, tácticas 
y herramientas. 

Una gran variedad de fuentes de información sobre inge- 
niería del software cliente/servidor está disponible en Inter- 
net. Una lista actualizada de referencias a sitios (páginas) web 
que son relevantes para sistemas C/S se pueden encontraren 
http://www.pressman5.com. 
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INGENIERÍA WEB 


A World Wide Web e Internet han introducido a la población en general en el mundo de 

la informática. Compramos fondos de inversión colectivos y acciones, descargamos 

música, vemos películas, obtenemos asesoramiento médico, hacemos reservas de habi- 
taciones en hoteles, vendemos artículos personales, planificamos vuelos en líneas aéreas, cono- 
cemos gente, hacemos gestiones bancarias, recibimos cursos universitarios, hacemos la compra 
-es decir, en el mundo virtual se puede hacer todo lo que se necesite —. Se puede decir que 
Internet y la Web son los avances más importantes en la historia de la informática. Estas tec- 
nologías informáticas nos han llevado a todos nosotros a la era de la informática (con otros 
millones de personas quienes finalmente entrarán también). Durante los primeros años del siglo 
veintiuno estas tecnologías han llegado casi a formar parte de nuestra vida diaria. 

Para todos nosotros que recordamos un mundo sin Web, el crecimiento caótico de la tecno- 
logía tiene su origen en otra era —los primeros días del software —. Eran tiempos de poca dis- 
ciplina, pero de enorme entusiasmo y creatividad. Eran tiempos en que los programadores a 
menudo entraban en otros sistemas, algunas veces con buena intención y otras con mala inten- 
ción. La actitud que prevalecía parecía ser la de «Hazlo rápidamente, y entra en el campo, que 
nosotros lo limpiaremos (y mejor sería que entendieras lo que realmente queremos construir) 
cuando actuemos». ¿Le suena familiar? 

En una mesa redonda virtual publicada en IEEE Software [PRE98], mantuve en firme mi 
postura en relación con la ingeniería de Web: 


Me parece que cualquier producto o sistema importante es merecedor de recibir una ingeniería. Antes 
de comenzar a construirlas, lo mejor es entender el problema, diseñar una solución viable, implementarla 
de una manera sólida y comprobarla en profundidad. Probablemente también se deberían controlar los 
cambios a medida que el trabajo vaya avanzando, y disponer de mecanismos para asegurar la calidad del 
resultado final. Muchos de los que desarrollan Webs no dicen lo mismo; ellos piensan que su mundo-es 
realmente diferente, y que simplemente no se van a aplicar los enfoques de ingeniería del software con- 
vencionales. 


VISTAZO RÁPIDO 


¿Qué es? Los sistemas y aplicaciones 


(WebApps) basados en Web hacen posi- 
ble queuna poblaciónextensa de usua- 
rios finales dispongan de una gran 
variedad de contenido y funcionalidad, 
La ingeniería Webno es un clónicoper- 
fectode la ingeniería del software, pero 
toma prestado muchos de los concep- 
tos y principios básicos de la ingenie- 
ría del software, dando importancia a 
las mismas actividades técnicas y de 
gestión. Existen diferencias sutiles en 
la forma en que se llevan a cabo estas 
actividades,pero la filosofía primordial 
esidéntica dado que dicta un enfoque 
disciplinado para el desarrollo de un 
sistema basado en computadora. 


¿Quién lo hace? Los ingenieros Web y 


los desarrolladores de contenido no 
técnicos crean las WebApps. 


¿Por qué es importante? A medida 


quelas WebAppsse integran cada vez 
más en grandes y pequeñas compa- 


ñías (porejemplo, comercio electróni- 
co), y cada vez es más importante la 
necesidad de construir sistemas fia- 
bles, utilizables y adaptables. Esta es 
la razón por la que es necesario un 
enfoque disciplinado para el desarro- 
llo de WebApps. 


¿Cuáles son los pasos a seguir? Al 


igual que cualquier disciplina de inge- 
niería, la ingeniería Web aplica. un 
enfoque genérico que se suaviza con 
estrategias, tácticas y métodos espe- 
cializados. El proceso de ingeniería 
Webcomienza con una formulacióndel 
problema que pasa a resolverse con 
las WebApps. Se planifica el proyecto 
y se analizan los requisitos de la 
WebApp, entonces se lleva a cabo el 
diseño de interfaces arquitectónico y 
del navegador. El sistema se imple- 
menta utilizando lenguajes y herra- 
mientas especializados asociados con 
la Web, y entonces comienzan las prue- 
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bcs. Dado que las WebApps están en 
constante evolución, deben de esta- 
Haa===e los mecanismos para el con 
trol de configuraciones, garantía de 
calidad y soporte continuado. 


¿ Cuál es el producto obtenido? La 


elaboración de una gran variedad de 
productos de trabajo de ingeniería Web 
(por ejemplo, modelos de análisis. 
modelos de diseño, procedimientos de 
pruebas). Y como producto final la 
WebAppoperativa. 


¿ Cómo puedo estar seguro de que 


lo he hecho correctamente? Apli- 
candolas mismas prácticas SQAque se 
aplican en todos los procesos de inge- 
niería del software —las revisiones téc- 
nicas formales valoran los modelos de 
análisis y diseño—; las revisiones espe- 
cializadas tienen en consideración la 
usabilidad y la comprobación se apli- 
capara descubrir erroresenel conteni- 
do, funcionalidad y compatibilidad. 
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INGENIERÍA DEL SOFTWARE. Uls zoruyur ravsivw 
Esto nos lleva a formular una pregunta clave: ¿Pue- 


den aplicarse principios, conceptos y métodos de inge- 
niería en el desarrollo de la Web? Creo que muchos de 


- eres] ellos sí se pueden aplicar, pero su aplicación quizás 
A Sp pc y requiera un giro algo diferente. 
a Pero, ¿qué ocurriría si estuviera equivocado?, y ¿si 


; por tonto, también : ps 
po persiste el enfoque actual y específico para ese desa- 


rrollo de la Web? Con la ausencia de un proceso disci- 
plinado para sistemas basados en Web, cada vez nos 
preocupa más la manera en que nos podemos enfrentar con problemas serios para obtener éxito en el desarrollo, 
empleo y «mantenimiento» de estos sistemas. En esencia, a medida que entramos en el nuevo siglo, la infraes- 
tructura de las aplicaciones que se están creando hoy en día puede llevamos a algo que se podría llamar «Web 
enmarañada». Esta frase connota un cúmulo de aplicaciones basadas en Web pobremente desarrolladas y con una 
probabilidad de fallo bastante alta. Y lo que es peor, a medida que los sistemas basados en Web se van compli- 
cando, un fallo en uno de ellos puede propagar y propagará problemas muy extensos en todos. Cuando ocurra esto, 
la confianza en Internet se puede romper provocando resultados irremediables. Y lo que es aún peor, puede con- 
ducir a una regulación gubernamental innecesaria y mal concebida, provocando daños irreparables en estas tec- 
nologías singulares. 

Con objeto de evitar una Web enmarañada y lograr un mayor éxito en el desarrollo y aplicación de sistemas 
basados en Web complejos y a gran escala, existe una necesidad apremiante de enfoques de ingeniería Web disci- 
plinada y de métodos y herramientas nuevos para el desarrollo, empleo y evaluación de sistemas y aplicaciones 
basados en Web. Tales enfoques y técnicas deberán tener en cuenta las características especiales en el medio nue- 
vo, en los entornas y escenarios operativos, y en la multiplicidad de perfiles de usuario implicando todo ello un 
reto adicional para el desarrollo de aplicaciones basadas en Web. 

La Ingeniería Web (IWeb) está relacionada con el establecimiento y utilización de principios científicos, de 
ingeniería y de gestión, y con enfoques sistemáticos y disciplinados del éxito del desarrollo, empleo y manteni- 
miento de sistemas y aplicaciones basados en Web de alta calidad [(MUR99]. 


No hay mucho que decir con respecto al hecho de que el mundo). De forma alternativa, una aplicación se pue- 
los sistemas y las aplicaciones' basados en Web (nos de ubicar en una Intranet (implementando la comuni- 
referiremos a estas como WebApps) son muy diferentes cación a través de redes de una organización) o una 
de las otras categorías de software informático que se Extranet (comunicación entre redes). 

tratan en el Capítulo 1. Powell resume las diferencias 

básicas cuando afirma que los sistemas basados en Web $ 
«implican una mezcla de publicación impresa y desa- CLAVE 
rrollo de software,de marketing e informática,de comu- 
nicaciones internas y relaciones externas, y de arte y 
tecnología» [POW98]. Los atributos siguientes se van 
a encontrar en la gran mayoría de las WebApps?: 


Intensivas de Red. Por su propia naturaleza, una 
WebApp es intensiva de red. Reside en una red y debe Controlada por el contenido. En muchos casos, la 
dar servicio a las necesidades de una comunidad diver- función primaria de una WebApp es utilizar híperme- 
sa de clientes. Una WebApp puede residir en Internet dia para presentar al usuario el contenido de textos, grá- 
(haciendoposible asíuna comunicación abiertapartodo ficos, sonido y vídeo. 


$] 


las WebApps son intensivasde red, controladas 

por el contenido y en continua evolución. Estos atributos 
tienen un profundo impacto dentro de la forma 

en que se lleva a coba la Web. 


* En esta categoria se incluyen unos sitios Web completos, funcio 2 En el contexto de este capitulo el termino «aplicación Web» abar- 
nalidad especializada dentro de los sitios Web y aplicaciones de pro- cara todo, desde una pagina Web simple que podria ayudar a un con- 
ceso de informacion que residen en Internet, en una Intranet o en sumidor a calcular el pago de un alquiler de un coche hasta un sitio 
una Extranet Web completo que proporcione los servicios completos para viales 


de negocios y de vacaciones 
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Evolución continua. A diferencia del software de apli- 
caciones convencional, que evoluciona con una serie de 
versiones planificadas y cronológicamente espaciadas, 
las aplicaciones Web están en constante evolución. No 
es inusual que algunas WebApps (específicamente, su 
contenido) se actualicen cada hora. 


Algunos argumentan que la evolución continua de 
las WebApps hace que el trabajo realizado en ellas sea 
similar a la jardinería. Lowe [LOW99] trata este tema 
con el siguiente escrito: 

La ingeniena está a punto de adoptar un enfoque cientí- 
fico y consecuente, suavizado por un contexto específico y 
práctico, para el desarrollo y el comisionado de sistemas y 
aplicaciones. El desarrollo de los sitios Web suele estar des- 
tinado a crear una infraestructura (sembrarel jardín) y enton- 
ces «ocuparse» de la información que crece y brota dentro 
del jardín. Después de un tiempo, el jardín (es decir, el sitio 
Web) continuará evolucionando, cambiando y creciendo. 
Una buena arquitecturainicial deberá permitir que este cre- 
cimiento ocurra de forma controlada y consecuente... podrí- 
amos hacer que «tres cirujanos» podaran los «árboles» (es 
decir, las secciones del sitio Web) dentro dei jardín (el sitio 
en sí) a la vez se asegurala integridad de las referencias cru- 
zadas. Podríamos disfrutar de «guarderías de jardín» donde 
«se cultiven» las plantasjóvenes (es decir, las configuracio- 
nes de diseño para sitios Web). Acabemos con esta analogía, 
no vaya a ser que vayamos demasiado lejos. 


Un cuidado y una alimentación continua permite que 
un sitio Web crezca (en robustez y en importancia). Pero 
a diferencia de un jardín, las aplicaciones Web deben 
de servir (y adaptarse a) las necesidades de más de un 
jardinero, Las siguientes características de WebApps 
son las que conducen el proceso: 


Inmediatez. Las aplicaciones basadas en Web tienen 
una inmediatez [NOR99] que no se encuentra en otros 
tipos de software. Es decir, el tiempo que se tarda en 
comercializar un sitio Web completo puede ser cuestión 
de días o semanas*. Los desarrolladores deberán utili- 
zar los métodos de planificación, análisis, diseño, imple- 
mentación y comprobación que se hayan adaptado a 
planificaciones apretadas en tiempo para el desarrollo 
de WebApps. 


o 


No hay duda de que la inmediatez a menudo prevalece 
en eldesarrollo de las WebApps, pero hay que tener 
cuidodo, porque el hecho de hacer algo rávidomente 
no significo tener el privilegio de hacer un trabajo 

de ingenieríopobre. lo rápido y erróneo raras veces 
tiene un resultado acepíable. 


Seguridad. Dado que las WebApps están disponibles 
a través del acceso por red, es difícil, si no imposible, 
limitarla población de usuarios finales que pueden acce- 
der a la aplicación. Con objeto de proteger el conteni- 
do confidencial y de proporcionar formas seguras de 
transmisión de datos, deberán implementarse fuertes 


3 Páginas Web sofisticadas pueden elaborarse en pocas horas 
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medidas de seguridaden toda la infraestructuraque apo- 
ya una WebApp y dentro de la misma aplicación. 


Estética. Una parte innegable del atractivo de una 
WebApp es su apariencia e interacción. Cuando se ha 
diseñado una aplicación con el fin de comercializarse o 
vender productos o ideas, la estética puede tener mucho 
que ver con el éxito del diseño técnico. 


Las características generales destacadas anterior- 
mente se aplican a todas las WebApps, pero con un gra- 
do diferentede influencia. Las categoríasde aplicaciones 
que se enumeran a continuación son las más frecuentes 
en el trabajo de la Web[DAR99]: 


informativa: se proporcionaun contenido solo de lec- 
tura con navegación y enlaces simples; 


descarga: un usuario descarga la información desde 
el servidor apropiado; 


personalizable: el usuario personaliza el contenido 
a sus necesidades específicas; 


¿Cómo se pueden 
tategorizar las WebApps? 


interacción: la comunicación entre una comunidad 
de usuarios ocurre mediante un espacio chat (charla), 
tablones de anuncios o mensajería instantánea; 


entrada del usuario: la entrada basada en formula- 
rios es el mecanismo primario de la necesidad de 
comunicación; 

orientada a transacciones: el usuario hace una soli- 
citud (por ejemplo, la realización un pedido) que es 
cumplimentado por la WebApp; 


orientado a servicios: la aplicación proporciona un 
servicio al usuario, por ejemplo, ayuda al usuario a 
determinar un pago de hipoteca; 


portal: la aplicación canaliza al usuario llevándolo 
a otros contenidos o servicios Web fuera del domi- 
nio de la aplicación del portal; 


acceso a bases de datos: el usuario consulta en una 
base de datos grande y extrae información; 


almacenes de datos: el usuario hace una consulta en 
una colección de bases de datos grande y extrae infor- 
mación. 

Las características y las categorías destacadas ante- 
riormente en esta sección, y las categorías de aplica- 
ciones representan los hechos reales para los ingenieros 
de la Web. La clave es vivir dentro de las restricciones 
impuestas por las características anteriores y aun así 
tener éxito en la elaboración de la WebApp. 


29,1.1. Atributos de calidad 


Todas las personas que hayan navegado alguna vez por la 
Web o hayan utilizado una intranet de una compañía pue- 
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den opinar sobre lo que hace una «buena» WebApp. Los 
puntos de vista individuales varían enormemente. Algu- 
nos usuarios disfrutan con gráficos llamativos, en cambio 
otros solo quieren un texto sencillo.Algunos exigen infor- 
mación copiosa, otros desean una presentación abreviada. 
En efecto, la percepción de «lo bueno» por parte del usua- 
rio (y como consecuencia, la aceptación o no aceptación 
resultante de la WebApp) podría ser más importante que 
cualquierdiscusión técnica sobre la calidad de la WebApp. 

Pero ¿cómo se percibe la calidad de la WebApp? 
¿qué atributos deben de exhibirse ante los ojos de los 
usuarios para lograr lo bueno y al mismo tiempo exhi- 
bir las características técnicas de calidad que permitan 
a un ingeniero corregir, adaptar, mejorar y soportar la 
aplicación a largo plazo? 


E 


Arbol detallado de los requisitos 
de calidad para WebApps 


3 


En realidad, todas las características generales de la 
calidad del software estudiadas en los Capítulos 8, 19 
y 24 se aplican también a las WebApps. Sin embargo, 
las características más relevantes —usabilidad, fiabili- 
dad, eficiencia y capacidad de mantenimiento— pro- 
porcionan una base Útil para evaluar la calidad de los 
sistemas basados en Web. 

Olsina y sus colaboradores [OSL99] han preparado 
un «árbol de requisitos de calidad» que identifica un 
conjunto de atributos que conduce a WebApps de alta 
calidad. La Figura 29.1 resume su trabajo. 


Capacidad de comprensión del sitio global 
Sevicios de ayuda y realimentación en línea 
Capacidades estéticas y de interfaz 
Servicios especiales 


Capacidad de recuperación y de búsqueda 
Servicios de búsqueda y navegación 
Servicios relacionados con el dominio de aplicación 


á 
N 


Proceso correcto de enlace 
Recuperación de errores . 
Validación y recuperación de la entrada del usuario 


Rendimiento del tiempo de respuesta 
Velocidad de generación de páginas 
Velocidad de generación de gráficos 


Facilidadde corrección 
7 Adaptabilidad 
Extensibilidad 


Capacidad de 
mantenimiento 


FIGURA 29.1. Árbol de requisitos de calidad (OSL 99). 


29.1.2. Las tecnologías 


El diseño y la implementación de sistemas basados en 
Web incorporan tres tecnologías importantes: el desarro- 
llo basado en componentes, la seguridad y los estándares 
de Internet. Un ingeniero Web deberá estar familiarizado 
con las tres para construir WebApps de alta calidad. 
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Desarrollo basado en componentes 

Las tecnologías de componentes estudiadas en los Capí- 
tulos 27 y 28 han evolucionado en gran parte gracias al 
crecimiento explosivo de los sistemas y aplicaciones 
basados en Web. Retomandoel estudio del capítulo ante- 
rior, los ingenieros Web disponen de tres estándares 
importantes para la infraestructura: CORBA, 
COM/DCOM y JavaBeans. Estos estándares (acompa- 
ñados por los componentes preconstmidos, herramientas 
y técnicas) proporcionan una infraestructuraque permite 
a los que diseñan emplear y personalizar componentesde 
terceras partes permitiéndoles así comunicarse unos con 
otros y con servicios a nivel de sistemas. 


esgado para dirigir 

controlar los mercancías 

todos lados nos podemos 

informáticos (hackers), 

¡sistemas informáticos (crackers), 

os, impostores, metomentodos, 

hurtadores, conspiradores, 

de Coballo de Troya, emisores 

lores de programas malévolos. 
Peter Denning 


Seguridad 

Si en una red reside una WebApp, ésta está abierta a un 
acceso sin autorización. En algunos casos, ha sido el per- 
sonal interno el que ha intentado acceder sin autorización. 
En otros casos, intrusos (hackers) pueden intentar acce- 
der por deporte, por sacar provechoo con intencionesmás 
maliciosas. Mediante la infraestructurade red se propor- 
ciona una variedad de medidas de seguridad, tales como 
encriptación, cortafuegos y otras. Un estudio amplio de 
este tema queda fuera del ámbito de este libro. Para más 
información, el lector interesado puede consultar en esta 
bibliografía: [ATK97], [KAE99] y [BRE99]. 


Estándares de Internet 
Durante la última década el estándar dominante en la 
creación del contenido y la estructura de la WebApp ha 
sido HTML, un lenguaje de marcas que posibilita al desa- 
rrollador proporcionar una serie de etiquetas que des- 
criben una gran variedad de objetos de datos (texto, 
gráficos, audio/vídeo, formularios, etc.). Sin embargo, a 
medida que las aplicaciones crecen en tamaño y com- 
plejidad, se ha adoptado un nuevo estándar —XML— 
para la próxima generación de WebApps. XML 
(Extensible Markup Language) el Lenguaje de marcas 
extensible es un subconjunto estrictamente definido del 
metalenguaje SGML[BRA97], permitiendo que los dise- 
ñadores definan etiquetas personalizadas en las descrip- 
ciones de una página Web. Mediante una descripción del 
metalenguaje XML, el significado de las etiquetas per- 
sonalizadas se define en la información transmitida al 
sitio del cliente. Para más información sobre XML, el 
lector interesado deberá consultar [PAR99] y [STL99]. 
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Las características de sistemas y aplicaciones basados 
en Web influyen enormemente en el proceso de TWeb. 
La inmediatez y la evolución continúan dictando un 
modelo de proceso incremental e interactivo (Capítulo 
2) que elabora versiones de WebApps muy rápidamen- 
te. La naturaleza intensiva de red de las aplicaciones en 
este dominio sugiere una población de usuarios diver- 
sa (exigiendo especialmente la obtención y modelado 
de requisitos), y una arquitectura de aplicación que pue- 
da ser altamente especializada (realizando de esta mane- 
ra exigencias en el diseño). Dado que las WebApps 


suelen ser controladas por el contenido haciendo hin- 
capié en la estética, es probable que las actividades de 
desarrollo paralelas se planifiquen dentro del proceso 
TWeb y necesiten un equipo de personas tanto técnicas 
como no (por ejemplo, redactores publicitarios, dise- 
ñadores gráficos). 


YN 
a 


CLAVE 
La Web demonda un proceso de softwore 
incremental y evolutivo 


A medida que la evolución de las WebApps pasa de uti- 
lizar recursos estáticos de información controlada por 
el contenido a utilizar entornos de aplicaciones diná- 
micos controlados por el usuario, cada vez es más impor- 
tante la necesidad de aplicar una gestión sólida y unos 
principios de ingeniería. Para conseguir esto, es nece- 
sario desarrollar un marco de trabajo IWeb que acom- 
pañe a un modelo de proceso eficaz, popularizado por 
las actividades* del marco de trabajo y por las tareas de 
ingeniería. En la Figura 29.2 se sugiere un modelo de 
proceso para IWeb. 

El proceso IWeb comienza con la formulación —acti- 
vidad que identifica las metas y los objetivos de la WebApp 
y establece el ámbito del primer incremento—. 


Diseño 
arquitectónico 
Diseño de 
navegación 
Diseño de 
la interfaz 


Generación 
de páginas 
y pruebas 


Evaluación | 
del cliente 


FIGURA 29.2. El modelo de proceso Web. 


La planificación estima el coste global del proyecto, 
evalúa los riesgos asociados con el esfuerzo del desa- 
rrollo, y define una planificación del desarrollo bien gra- 
nulada para el incremento final de la WebApp, con una 
planificación más toscamente granulada para los incre- 
mentos subsiguientes. El análisis establece los requisi- 


á Retomando el estudio de los modelos de proceso del Capítulo 2, las 
actividades del marco de trabajo se realizan para todas las WebApps, 
mientras que las tareas se adaptan al tamaño y a la complejidad de 
la WebApp que se va a desarrollar. 
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tos técnicos para la WebApp e identifica los elementos 
del contenido que se van a incorporar. También se defi- 
nen los requisitos del diseño gráfico (estética). 

La actividad de ingeniería incorpora dos tareas para- 
lelas, como se muestra a la derecha en la Figura 29.2. El 
diseño del contenido y la producción son tareas lleva- 
das a cabo por personas no técnicas del equipo IWeb. El 
objetivo de estas tareas es diseñar, producir, y/o adqui- 
rir todo el contenido de texto, gráfico y vídeo que se 
vayan a integrar en la WebApp. Al mismo tiempo, se lle- 
va a cabo un conjunto de tareas de diseño (Sección 29.5) 

La generación de páginas es una actividad de cons- 
trucción que hace mucho uso de las herramientas auto- 
matizadas para la creación de la WebApp. El contenido 
definido en la actividad de ingeniería se fusiona con los 
diseños arquitectónicos, de navegación y de la interfaz para 
elaborar páginas Web ejecutables en HTML, XML y otros 
lenguajes orientados a procesos (por ejemplo, Java). Duran- 
te esta actividad también se lleva a cabo la integración con 
el software intermedio (middleware) de componentes (es 
decir, CORBA, DCOM o JavaBeans). Las pruebas ejer- 
citan la navegación, intentan descubrir los errores de las 
applets, guiones y formularios, y ayuda a asegurar que la 
WebApp funcionará correctamente en diferentes entornos 
(por ejemplo, con diferentes navegadores). 


Referencia Web 


W3C es un consorcio de industria que proporciona 
acceso a información WWW de interés 

para los ingenieros de Web, y se puede encontrar 
en la dirección www.w3.org 


Cada incremento producido como parte del proceso 
IWeb se revisa durante la actividad de evaluación del 
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cliente. Es en este punto en donde se solicitan cambios 
(tienen lugar ampliaciones del ámbito). Estos cambios 


se integran en la siguiente ruta mediante el flujo incre- 
mental del proceso. 


La formulación y el análisis de sistemas y aplicaciones 
basados en Web representan una sucesión de activida- 
des de ingeniería Web que comienza con la identifica- 
ción de metas globales para la WebApp, y termina con 
el desarrollo de un modelo de análisis o especificación 
de los requisitos para el sistema. La formulación per- 
mite que el cliente o diseñador establezca un conjunto 
común de metas y objetivos para la construcción de la 
WebApp. También identifica el ámbito de esfuerzo en 
el desarrollo y proporciona un medio para determinar 
un resultado satisfactorio. El análisis es una actividad 
técnica que identifica los datos y requisitos funcionales 
y de comportamiento para la WebApp. 


294.1. Formulación 


Powell [POW98] sugiere una serie de preguntas que 
deberán formularse y responderse al comienzo de la eta- 
pa de formulación: 
+ ¿Cuál es la motivación principal para la WebApp? 
+ ¿Por qué es necesaria la WebApp? 
+. ¿Quién va a utilizar la WebApp? 

¿Qué preguntas 


2 se deberían hacer 


para formular el problema? 


La respuesta a estas preguntas deberá ser de lo más 
sucinto posible. Por ejemplo, supongamos que el fabri- 
cante de sistemas de seguridad en el hogar ha decidido 
establecer un sitio Web de comercio electrónico para 
vender sus productos directamente a los consumidores. 
Una frase que describiera la motivación de la WebApp 
podría ser la siguiente: 

HogarSegurolnc.com' permitirá a los consumidores confi- 


gurar y comprartodos los componentes necesarios para insta- 
lar un sistema de seguridad en casa o en su comercio. 


Es importante destacar que en esta frase no se ha pro- 
porcionado ningún detalle. El objetivo es delimitar la 
intención global del sitio Web. 

Después de discutir con otros propietarios de Hogar- 
Seguro Inc., la segunda pregunta se podría contestar de 
la siguiente manera: 

HogarSegurolnc.com nos permitirá vender directamente a 
los consumidores, eliminando por tanto los costes de interme- 
diarios, y mejorando de esta manera los márgenes de benefi- 


cios. También nos permitirá aumentar las ventas en un 25 por 
100 por encima de las ventas anuales y nos permitirá penetrar 


5 HogarSeguro ya se ha utilizado anteriormente como ejemplo en el 
libro. 
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en zonas geográficasen donde actualmente no tenemos alma- 
cenes de ventas. 


Finalmente, la compañía define la demografía para 
la WebApp: «Los usuarios potenciales de HogarSegu- 
rolnc.com son propietarios de casas y de negocios 
pequeños.» 

Las respuestas que se han establecido anteriormen- 
te implican metas específicas para el sitio Web Hogar- 
SeguroInc.com. En general, se identifican dos categorías 
[GNA99]: 

Metas informativas:indican la intención de propor- 
cionar el contenido y/o información específicos para 
el usuario final. 


Metas aplicables: indican la habilidad de realizar 
algunas tareas dentro de la WebApp. 


e, 

AVE 
Poro toda WebApp deberán definirse metas 
informativosy aplicables. 


En el contenido de la Web HogarSegurolnc.com,una 
meta informativa podría ser la siguiente: 


El sitio proporcionará alos usuarios especificacionesde un 
producto detallado, como descripción técnica, instruccionesde 
instalación e información de precios. 


El examen de las respuestas anteriores llevará a 
poderse aplicar la afirmación de meta siguiente: 


HogarSeguroInc.com consultará al cliente sobre la ins- 
talación (es decir, sobre la casa, oficina/almacén minoris- 
ta) que se va a proteger, y dará recomendaciones per- 
sonalizadas sobre el producto y la configuración que se va 
utilizar. 


Una vez que han identificado todas las metas apli- 
cables e informativas se desarrolla el perfil del cliente. 
El perfil del usuario recoge «las características rele- 
vantes de los usuarios potenciales incluyendo antece- 
dentes, conocimiento, preferencias e incluso más» 
[GNA99]. En el caso de HogarSegurolInc.com, el per- 
fil de usuario identificará las características de un com- 
prador típico de sistemas de seguridad (esta información 
sería proporcionada por el departamento de marketing 
de HogarSegurolnc.com). 

Una vez que se han desarrollado las metas y los per- 
files de usuarios, la actividad de formulación se centra en 
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la afirmación del ámbito para la WebApp (Capítulo 5). 
En muchos casos, las metas ya desarrolladas se integran 
en la afirmación del ámbito. Además es Útil, no obstan- 
te, indicar el grado de integración que se espera para la 
WebApp. Es decir, a menudo es necesario integrar los 
sistemas de informaciónexistentes (por ejemplo, la apli- 
cación de base de datos existente) en un planteamiento 
basado en Web. En este punto se tienen en consideración 
también los temas de conectividad. 


294,2. Análisis 


Los conceptos y principios que se trataron para el aná- 
lisis de los requisitos del software (Capítulo 11)se apli- 
can sin revisión en la actividad de análisis de ingeniería 
Web. Para crear un modelo de análisis completo para la 
WebApp se elabora el ámbito definido durante la acti- 
vidad de formulación. Durante la IWeb se realizan cua- 
tro tipos de análisis diferentes: 


Análisis del contenido. Se trata de la identificación 
del espectro completo de contenido que se va a pro- 
porcionar. En el contenido se incluyen datos de texto, 
gráficos, imágenes, vídeo y sonido. Para identificar y 
describir cada uno de los objetos de datos que se van a 
utilizar dentro de la WebApp se puede utilizar el mode- 
lado de datos (Capítulo 12). 


Análisis de la interacción. Se trata de la descrip- 
ción detallada de la interacción del usuario y la 
WebApp. Para proporcionar descripciones detalladas 
de esta interacción se pueden desarrollar casos prácti- 
cos (Capítulo 11). 


Análisis funcional. Los escenarios de utilización 
(casos de uso) creados como parte del análisis de inte- 
racción definen las operaciones que se aplicarán en el 
contenido de la WebApp e implicarán otras funciones 
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lento [WebApps] 
mejor 

nte y de forma 

ño a través de usuarios 


de procesamiento. Aquí serealiza una descripción deta- 
llada de todas las funciones y operaciones. 


Análisis de la configuración.Se efectúa una des- 
cripción detallada del entorno y de la infraestructura en 
donde reside la WebApp. La WebApp puede residir en 
Internet, en una intranet o en una Extranet. Además, se 
deberá identificar la infraestructura (es decir, la infra- 
estructura de los componentes y el grado de utilización 
de la base de datos para generar el contenido) de la 
WebApp. 

Aun cuando se recomienda una especificación 
detallada de los requisitos para WebApps grandes y 
complejas, tales documentos no son los usuales. Se 
puede decir que la continua evolución de los requisi- 
tos de la WebApp puede hacer que cualquier docu- 
mento se quede obsoleto antes de finalizarse. Aunque 
se puede decir que esto sucede de verdad, es necesa- 
rio definir un modelo de análisis que pueda funcio- 
nar como fundamento de la siguiente actividad de 
diseño. Como mínimo, la información recogida duran- 
te las cuatro tareas de análisis anteriores deberá ser 
revisada, modificada a petición, y organizada para 
formar un documento que pueda pasarse a los dise- 
ñadores de WebApps 


ACIONE 


La naturaleza de inmediatez de las aplicaciones basadas en 
Web unida a la presión de evolucionar continuamente obli- 
ga a que un ingenieroestablezcaun diseño que resuelva el 
problema comercial inmediato, mientras que al mismo tiem- 
po obliga a definir una arquitectura de aplicaciónque ten- 
ga la habilidad de evolucionarrápidamentecon el tiempo. 
El problema, desde luego, es que resolver (rápidamente) el 
problema inmediato puede dar comoresultado compromi- 
sos que afectan a la habilidad que tiene la aplicacióndeevo- 
lucionar con el paso del tiempo. 


Referencia 


Uno fuente veliosa de líneas generoles prácticos 

para el diseño de sitios Web se puede encontrar en 
www.ibm.com /ibim/easy / design /lower / 
1060100.html 
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Con objeto de realizar un diseño eficaz basado en 
Web, el ingeniero deberá trabajar reutilizando cuatro 
elementos técnicos [NAN98]: 


Principios y métodos de diseño.Es importante des- 
tacar que los conceptos y principios del diseño estu- 
diados en el Capítulo 13 se aplican a todas las WebApps. 
La modularidad eficaz (exhibida con una cohesión alta 
y con un acoplamiento bajo), la elaboración paso a paso, 
y cualquier otra heurística de diseño del software con- 
ducirá a sistemas y aplicaciones basados en Web más 
fáciles de adaptar, mejorar, probar y utilizar. 

Cuando se crean aplicaciones Web se pueden reutili- 
zar los métodos de diseño que se utilizan para los siste- 
mas orientados a objetos estudiados anteriormente en 
este libro. La hipermedia define «objetos» que interac- 
túan mediante un protocolo de comunicación algo simi- 
lar a la mensajería. De hecho, la notación de diagramas 
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propuesta por UML (Capítulos 21 y 22) puede adaptar- 
se y utilizarse durante las actividades de diseño de las 
WebApps. Además, se han propuesto otros hipermedios 
de métodos de diseño (por ejemplo, [ISA95], [SCH96]). 


diseño de Web se centra 

'e interacción... 

desestructuror lo información 
espacio del documento. 

in consideror el diseño Web 

zado pora construir 

ealidad, el diseño incluye 


Reglas de oro. Las aplicaciones hipermedia inte- 
ractivas (WebApps) llevan construyéndose ya hace una 
década. Durante ese tiempo, los diseñadores han desa- 
rrollado un conjunto de heurísticas de diseño (reglasde 
oro)que se podrán volver a aplicar durante el diseño de 
aplicaciones nuevas. 


Configuracionesde diseño. Como se ha destacado 
anteriormente en este libro, las configuraciones de dise- 
ño son un enfoque genérico para resolver pequeños pro- 
blemas que se pueden adaptar a una variedad más amplia 
de problemas específicos. En el contexto de las 
WebApps, las configuraciones de diseño se pueden apli- 
car no solo a los elementos funcionales de una aplica- 
ción, sino también a los documentos, gráficos y estética 
general de un sitio Web. 


Plantillas. Las plantillas se pueden utilizar para pro- 
porcionar un marco de trabajo esquemático de cualquier 
configuración de diseño o documento a utilizar dentro 
de una WebApp. Nanard y Kahn [NAN98] describen 
este elemento de diseño reutilizable de la siguiente 
manera: 


CEE 
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FIGURA 29.3. Estructuras lineales. 


NES 


Una vez que se ha especificadouna plantilla, cualquier par- 
te de una estructura hipermedia que se acopla a esta plantilla 
se podrá generar o actualizar automáticamente llamando sola- 
mente a la plantilla con datos relevantes [para dar cuerpo al 
esquema]. La utilización de plantillas constructivas depende 
implícitamente del contenido separado de los documentos hiper- 
media, de la especificación y de su presentación: los datos fuen- 
te se organizan en la estructura del hipertexto tal y como se 
especifica en la plantilla 


29.5,1, Diseño arquitectónico 


El diseño arquitectónico para los sistemas y aplicacio- 
nes basados en Web se centra en la definición de la 
estructura global hipermedia para la WebApp, y en la 
aplicación de las configuraciones de diseño y plantillas 
constructivas para popularizar la estructura (y lograr la 
reutilización). Una actividad paralela, llamada diseño 
del contenido?, deriva la estructura y el formato deta- 
llados del contenido de la información que se presenta- 
rá como parte de la WebApp. 


Cons) 


la mayoría de las estructuras de las WebApos 
simplemente aparecen. Evite esto trampa. Establezca 
el diseña estructuralde la WebApo explicitamente 
antes de empezar a desarrollar los detalles de la págino 
y de la navegación. 


Estructuras de las WebApps 
La estructura arquitectónica global va unida a las metas 
establecidas para una WebApp, al contenido que se va 
a presentar, a los usuarios que la visitarán y a la filoso- 
fía de navegación (Sección 29.5.3) establecidos. Cuarr 
do el encargado de la arquitectura va a realizar el diseño 
de una WebApp típica puede elegir entre cuatro fuen- 
tes diferentes [POW98]7. 
¿Cuáles son las opciones 


$ disponibles para el diseño de 
una WebApp? 


Las estructuras lineales (Fig. 29.3) aparecen cuan- 
do es común la sucesión predecible de interacciones 
(con alguna variación o diversificación). Un ejemplo 
clásico podría ser la presentación de un manual de usua- 
rio en la que las páginas de información se presentan 
con gráficos relacionados, vídeos cortos O sonido solo 
después de haber presentado un prerrequisito. La suce- 
sión de presentación del contenido queda predefinida y 
se puede decir que, generalmente, es lineal. Otro ejem- 
plo podría ser la sucesión de una entrada de pedido de 
un producto donde se tenga que especificar la informa- 
ción específica en un orden específico. En tales casos, 


$ El diseño del contenido es una actividad no técnica que llevan a 
cabo redactores publicitarios, artistas, diseñadores gráficos y otros 
que generan el contenido de las WebApps. Para más información, 
véase [DIN98] y [LYN99]. 
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las estructuras que se muestran en la Figura 29.3 son las 
adecuadas. A medida que el contenido y el procesa- 
miento crecen en complicación, el flujo puramente line- 
al que se muestra a la derecha da como resultado 
estructuras lineales más sofisticadas en las que se pue- 
de invocar el contenido alternativo, o en donde tiene 
lugar una desviación para adquirir un contenido com- 


plementario (la estructura se muestra a la derecha en la 
Fig. 29.3). 
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FIGURA 29.4. Estructura reticular. 


Las estructuras reticulares (Fig. 29.4) son una opción 
arquitectónica que puede aplicarse cuando el contenido 
de la WebApp puede ser organizado categóricamenteen 
dos dimensiones (o más). Por ejemplo, consideremos una 
situación en la que un sitio de comercio electrónico ven- 
de palos de golf. La dimensión horizontal de la retícula 
representa el tipo de palo en venta (por ejemplo, made- 
ras, hierros, wedges, putters). La dimensión vertical repre- 
senta la oferta proporcionada por los fabricantesde palos 
de golf. De aquí que un usuario pueda navegar por la retí- 
cula horizontalmente para encontrar la columna de los 
putters, y recorrer la columna para examinar las ofertas 
proporcionadas por los vendedores de putters. Esta arqui- 
tectura WebApp es de utilidad solo cuando se encuentra 
un contenido muy regular [POW98]. 


AVE 


Las estructuras reticulares fundonan kien cuando 


el contenido puede organizarse categóricamente 
en dos dimensiones o más. 


Las estructuras jerárquicas (Fig. 29.5) son sin duda la 
arquitectura WebApp más común. A diferenciade la divi- 
sión de jerarquías de software estudiadas en el Capítulo 
14, que fomentan el flujo de control solo a lo largo de las 
ramas verticales de la jerarquía, se podrá diseñar una 
estructura jerárquica de la WebApp para posibilitar (por 
medio de la ramificación de hipertexto) el flujo de con- 
trol en horizontal atravesando las ramas verticales de la 
estructura. Por tanto, el contenido presentado en la rama 
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del extremoizquierdode lajerarquía puede tener enlaces 
de hipertexto que lleven al contenido que existe en medio 
de la rama derecha de la estructura. Sinembargo, debería 
de destacarse que aunque dicha rama permita una nave- 
gación rápida por el contenido de la WebApp, puede ori- 
ginar también confusión por parte del usuario. 


Cons 


El acoplamiento es un temoengañoso poro 

lo arquitectura de los WebApps. Por un lodo, facilita 
lo navegación. Pero, por otro, tambiénpuede hacer 
que elusuario «se pierdo». No rehogo conexiones 
horizontales dentro de unojerorquío. 


Í 


E 
ña 


a 


-— 


el 


FIGURA 29.5. Estructuras jerárquicas. 


Una estructura en red o de «web pura» (Fig. 29.6) 
se asemejaen muchos aspectos a la arquitectura en evo- 
lución para los sistemas orientados a objetos. Los com- 
ponentes arquitectónicos (en este caso las páginas Web) 
se diseñan de forma que pueden pasar el control 
(mediante enlaces de hipertexto) a otros componentes 
del sistema. Este enfoque permite una flexibilidad de 
navegación considerable, aun cuando puede resultar 
confuso para el usuario. 


7-15 


eN 


FIGURA 29.6. Estructura en red o «web pura)). 


Las estructuras arquitectónicas estudiadas en los 
párrafos anteriores se pueden combinar para formar estruc- 
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turas compuestas. La arquitectura global de una WebApp 
puede serjerárquica, pero parte de la estructura puede 
exhibir características lineales, mientras que otra parte de 
la arquitectura puede confeccionarse en red. La meta del 
diseñador arquitectónico es hacer corresponderla estruc- 
tura de la WebApp con el contenido que se va a presen- 
tar y con el procesamiento que se va a llevar a cabo. 


Patrones de diseño 

Como se ha destacado anteriormente en este mismo 
libro, los patrones de diseño son un buen método para 
resolver pequeños problemas que pueden adaptarse a 
una variedad mucho más amplia de problemas especí- 
ficos. En el contexto de los sistemas y aplicacionesbasa- 
dos en Web, los patrones de diseño pueden aplicarse en 
el nivel jerárquico, nivel de componentes y nivel de 
hipertexto (de navegación). 


En los Copítulos 14 y 22 se puédé encontrar más 
información sobre las corfiguracionesde diseño. 


Cuando dentro de una WebApp se requiere la fun- 
cionalidad del proceso de datos, pueden aplicarse los 
patrones de diseño arquitectónicas a nivel de compo- 
nentes propuestas por [BUS96], [GAM95] y otros. Los 
patrones de diseño a nivel de hipertexto se centran en 
el diseño de las características de navegación que per- 
miten al usuario moverse por el contenido de la WebApp 
fácilmente. Entre muchos de los patrones de diseño de 
hipertexto propuestos en literatura sobre este tema se 
encuentran los siguientes [BER98]: 


Ciclo: una configuración que devuelve al usuario al 
nodo de contenido visitado anteriormente. 


los configuraciones es una regla 
tres partes, y que expreso 

tte un cierto contexto, 

o solución. 


Anillo de Web: una configuración que implementa 
un «gran ciclo que enlaza hipertextos enteros via- 
jando por un tema» [BER98]. 

Contorno. un patrón que aparece cuando varios ciclos 
inciden en otro, permitiendo navegar por rutas defi- 
nidas por los ciclos. 


Contrapunto: un patrón que añade comentarios de 
hipertexto interrumpiendo la narrativa del contenido 
para proporcionar más información o más indagación. 
Mundo de espejo: el contenido se presenta utilizando 
diferentes hilos narrativos, cada uno con un punto de 
vista O perspectiva diferente. Por ejemplo, el conte- 
nido que describe una computadora personal podría 
permitir al usuario seleccionar una narrativa «téc- 
nica» o «no técnica» que describa la máquina. 
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Tamiz: una configuración que va guiando al usuario 
a través de una serie de opciones (decisiones) con el 
fin de llevar al usuario a un contenido específico e 
indicado por la sucesión de opciones elegidas o deci- 
siones tomadas. 


Vecindario: una configuración que abarca un marco 
de navegación uniforme por todas la páginas Web 
para permitir que un usuario tenga una guía de nave- 
gación consecuente independientemente de la loca- 
lización de la WebApp. 


Las configuraciones de diseño de hipertexto que se 
han descrito anteriormente se pueden reutilizar a medi- 
da que el contenido va adquiriendo el formato que per- 
mitirá la navegación a través de una WebApp. 


29.5.2. Diseño de navegación 


Una vez establecida una arquitectura de WebApp, una 
vez identificados los componentes (páginas, guiones, 
applets y otras funciones de proceso) de la arquitectu- 
ra, el diseñador deberá definir las rutas de navegación 
que permitan al usuario acceder al contenido y a los ser- 
vicios de la WebApp. Para que el diseñador pueda lle- 
varlo a cabo, debe (1) identificar la semántica de la 
navegación para diferentes usuarios del sitio; y (2) defi- 
nir la mecánica (sintaxis) para lograr la navegación. 

Generalmente una WebApp grande tendrá una varie- 
dad de roles de usuarios diferentes. Por ejemplo, los 
roles podrían ser el de visitante, cliente registrado o 
cliente privilegiado. Cada uno de estos roles se pueden 
asociar a diferentes niveles de acceso al contenido y de 
servicios diferentes. Un visitante puede tener acceso 
sólo a un contenido limitado, mientras que un cliente 
registrado puede tener acceso a una variedad mucho 
más amplia de información y de servicios. La semán- 
tica de la navegación de cada uno de estos roles sería 
diferente. 

El diseñador de WebApps crea una unidad semánti- 
ca de navegación (USN) para cada una de las metas aso- 
ciadas a cada uno de los roles de usuario [GNA99]. Por 
ejemplo, un cliente registrado puede tener seis metas 
diferentes, todas ellas con un acceso a información y 
servicios diferentes. Para cada meta se crea una USN, 
Gnaho y Larcher [GNA99] describen la USN de la 
siguiente manera: 


La estructura de una USN se compone de un conjunto de 
subestructuras de navegación que llamamos formas de nave- 
gación [WoN (Waysof navigating)]. Una WoN representa 
la mejor forma de navegación o ruta para que usuarios con 
ciertos perfiles logren su meta o submeta deseada. Por tan- 
to, el concepto de WoN se asocia al concepto de Perfil de 
Usuario. 


La estructura de una WoN se compone de un conjuntode 
nodos de navegación (NN) relevantes conectados a enlaces 
de navegación, entre los que algunas veces se incluyen las 
USNs. Eso significa que las USNs pueden agregarse para 
formar una USN de nivel superior, o anidarse en cualquier 
nivel de profundidad. 
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Una USN se compone de un conjunto de subestructuras 
de navegación llamadas ((formas de navegación)) (WoN). 
Una USN representa una meta de navegación específica 
para un tipo específico de usuario. 


Durante las etapas iniciales del diseño de navega- 
ción, para determinar una O más WoNs para cada meta 
de usuario, se evaluará la estructura de la WebApp 
(arquitectura y componentes). Como se ha destacado 
anteriormente, una WoN identifica los nodos de nave- 
gación (por ejemplo, páginas Web), y entonces los enla- 
ces que hacen posible la navegación entre ellos. La WoN 
entonces se organiza en USNs. 

A medida que avanza el diseño, se va identificando la 
mecánica de cada enlace de navegación. Entre otras 
muchas opciones se encuentran los enlaces basados en 
texto, iconos, botones, interruptores y metáforas gráficas. 
El diseñador deberá elegirlos enlaces de navegación ade- 
cuados para el contenido y consecuentescon la heurísti- 
ca que conduce al diseño de una interfaz de alta calidad. 

Además de elegirla mecánica de navegación, el dise- 
ñador también deberá establecer las convencionesy ayu- 
das adecuadas. Por ejemplo, los iconos y los enlaces 
gráficos deberán tener un aspecto «clickable (capacidad 
de accederse)» con los bordes biselados, y dar así una 
imagen en tres dimensiones. La realimentación visual 
o de sonido se deberá diseñar para proporcionar al usua- 
rio una indicación de que se ha elegido una opción de 
navegación. Para la navegación basada en texto, se debe- 
rá utilizar el color que indica los enlaces de navegación 
y proporcionar una indicación de los enlaces por los que 
se ha navegado. Estas son solo unas pocas convencio- 
nes de las docenas que hacen que la navegación por la 
red sea agradable. Además de las convenciones, en este 
punto también se deberán diseñar ayudas de navegación 
tales como mapas de sitios, tablas de contenidos, meca- 
nismos de búsqueda y servicios dinámicos de ayuda 


29.5.3. Diseño de la interfaz 


Los conceptos, principios y métodos de diseños de inter- 
faz que se presentaron en el Capítulo 15 son todos apli- 
cables al diseño de interfaces de usuario para WebApps. 
Sin embargo, las características especiales de los siste- 
mas y aplicaciones Web requieren otras consideracio- 
nes adicionales. 


La interfaz de usuario de una WebApp es la «primera 
impresión». Independientemente del valor del conteni- 
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do, la sofisticación de las capacidades, los servicios de 
procesamiento y el beneficio global de la WebApp en 
sí, una interfaz con un diseño pobre decepcionará al 
usuario potencial y podrá de hecho hacer que el usua- 
rio se vaya a cualquier otro sitio. Dado el gran volumen 
de WebApps que compiten virtualmente en todas las 
áreas temáticas, la interfaz debe «arrastrar» inmediata- 
mente al usuario potencial. Nielsen y Wagner [NIE96] 
sugieren unas cuantas líneas generales y sencillas en el 
rediseño de una WebApp: 

Probabilidad de que los errores del servidor, incluso 
los más pequeños, hagan que el usuario abandone el 
sitio Web y busque información y servicios en algún 

¿Cuáles son algunas 


otro sitio. 
4 de las líneas generales 


básicas para el diseño 
de la interfaz de un sitio Web? 


La velocidad de lectura del monitor de una compu- 
tadora es aproximadamente un 25 por 100más lento 
que leer una copia impresa. Por tanto, no hay que obli- 
gar al usuario a leer cantidades voluminosas de texto, 
particularmente cuando el texto explica la operación 
de la WebApp o ayuda a navegar por la red. 


Evite los símbolos «bajo construcción» — levantan 
expectación y provocan un enlace innecesario que 
seguramente sea decepcionante —. 


Los usuarios prefieren no tener que recorrer la pan- 
talla. Dentro de las dimensiones normales de una 
ventana del navegador se deberá incluir información 
importante. 


Los menús de navegación y las barras de cabecera se 
deberán diseñar consecuentemente y deberán estar 
disponibles en todas las páginas a las que el usuario 
tenga acceso. El diseño no deberá depender de las fun- 
ciones del navegador para ayudar en la navegación. 


La estética nunca deberá sustituir la funcionalidad. 
Por ejemplo, un botón sencillo podría ser una opción 
de navegación mejor que una imagen 0 icono esté- 
ticamente agradables, pero vagos cuya intención no 
es muy clara. 


Referencia 


Uno de los mejores grupos de recursos de usabilidad 
de la Web ha sido recogido por el Grupo de Usabilidad, 
y se puede encontrar en la dirección 
www.usability.com/umi_links.htm 


Las opciones de navegación deberán ser obvias, 
incluso para el usuario casual. El usuario deberá bus- 
car la pantalla para determinarcómo enlazar con otro 
contenido o servicio. 
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Una interfaz bien diseñada mejora la percepción 
del contenido O de los servicios del usuario que pro- 
porciona el sitio Web. No tiene que ser necesaria- 
mente deslumbrante, pero deberá estar siempre bien 
estructurada y ergonómica. Un estudio completo 


de las interfaces WebApp de usuario está fuera 
del ámbito de este libro. Los lectores interesados 
pueden consultar [SAN96], [FLE98], [ROS98], o 
¡[LYN99] entre los cientos de ofertas que existen 
como guía. 


En el Capítulo 17, se destacó que las pruebas son el pro- 
ceso de ejercitar el software con la intención de encon- 
trar (y por último corregir) los errores. Esta filosofía 
fundamentalno se cambiará para el caso de las WebApps. 
De hecho, dado que los sistemas y aplicaciones basados 
en Webresiden en una red e interoperan con muchos sis- 
temas operativos diferentes, navegadores, plataformas de 
hardware, y protocolos de comunicación,la búsqueda de 
errores representa un reto significativopara los ingenie- 
¿Qué pasos hay que seguir 


ros Web. 
q para la comprobación de una 


WebApp? 


El enfoque de las pruebas de las WebApps adopta los 
principios básicos de todas las pruebas del software (Capí- 
tulo 17) y aplica estrategias y tácticas que ya han sido 
recomendadas para los sistemasorientados a objetos (Capí- 
tulo 23). Este enfoque se resume en los pasos siguientes: 


1. El modelo de contenidode la WebAppes revisadopara 
descubrir errores. Esta actividad de «prueba» se ase- 
meja en muchos aspectos a la de un corrector orto- 
gráfico de un documento escrito. De hecho, un sitio 
Web grande tendrá la capacidad de construir un lis- 
tado de los servicios de correctores profesionales para 
descubrir errores tipográficos, errores gramaticales, 
errores en la consistencia del contenido, errores en 
representaciones gráficas y de referencias cruzadas. 


es un negocio amargo para los que 
ln el software. Cuando ya se sabe qué 
plicor en una tecnología en particular, 

10 nueva (Internet y WebApps), y se 

Jos anteriores. 


. El modelo de diseño para la WebApp es revisado 
para descubrir errores de navegación. Los casos 
prácticos derivados como parte de la actividad de 
análisis permite que un ingeniero Web ejercite cada 
escenario de utilización frente al diseño arquitectó- 
nico y de navegación. En esencia, estas pruebas no 
ejecutables ayudan a descubrir errores en la nave- 
gación (por ejemplo, un caso en donde el usuario no 
pueda leer un nodo de navegación). Además, los enla- 
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ces de navegación (Sección 29.5.2) son revisados 
para asegurar su correspondencia con los especifi- 
cados en cada USN del rol de usuario. 


3. Se aplicanpruebas de unidad a los componentes de 
proceso seleccionados y las páginas Web. Cuando 
lo que se tiene en consideración es el tema de las 
WebApps el concepto de unidad cambia. Cada una 
de las páginas Web encapsulará el contenido, los enla- 
ces de navegación y los elementos de procesamiento 
(formularios, guiones, applets). No siempre es posi- 
ble o práctico comprobar cada una de las caracterís- 
ticas individualmente. En muchos casos, la unidad 
comprobable más pequeña es la página Web. A dife- 
rencia de la comprobación de unidades de software 
convencional, que tiende a centrarse en el detalle 
algorítmico de un módulo y los datos que fluyen por 
la interfaz del módulo, la comprobación por páginas 
se controla mediante el contenido, proceso y enla- 
ces encapsulados por la página Web. 


Referencia cruzada 


tos estrategios de integración se abarcan 
en los Capítulos 18 y 23. 


. Se construye la arquitectura, se realizan las pruebas 
de integración. La estrategia para la prueba de inte- 
gración depende de la arquitecturaque se haya elegido 
para la WebApp. Si la WebApp se ha diseñadocon una 
estructurajerárquica lineal, reticularo sencilla, es posi- 
ble integrar páginas Web de una manera muy similar 
a como se integran los módulos del software conven- 
cional. Sin embargo, si se utiliza una jerarquía mez- 
clada o una arquitectura de red (Web), la prueba de 
integración es similar al enfoqueutilizado para los sis- 
temas OO. La comprobación basada en hilos (Capí- 
tulo 23) se puede utilizar para integrar un conjunto de 
páginas Web (se puede utilizar una USN para definir 
el conjunto adecuado) que se requiere para responder 
aun sucesode usuario. Cada hilo se integra y se prueba 
individualmente. La prueba de regresión se aplica para 
asegurar que no haya efectos secundarios. La com- 
probación de agrupamientos integra un conjunto de 
páginas colaborativas (determinadasexaminando los 
casos prácticos y la USN). Los casos de prueba se deri- 
van para descubrir errores en las colaboraciones. 


. La WebApp ensamblada se prueba para conseguir 
unafuncionalidad global y un contenido. Al igual 
que la validación convencional, la validación de los 
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sistemas y aplicaciones basados en Web se centra en 
acciones visibles del usuario y en salidas reconoci- 
bles para el usuario que procedan del sistema. Para 
ayudar en la derivación de las pruebas de validación, 
las pruebas deberán basarse en casos prácticos. El 
caso práctico proporciona un escenario con una pro- 
babilidad alta de descubrir errores en los requisitos 
de interacción del usuario. 


6. La WebApp se implementa en una variedad de con- 
figuraciones diferentes de entornos y comprobar así 
la compatibilidad con cada configuración. Se crea 
una matriz de referencias cruzadas que define todos 
los sistemas operativos probables, plataformas de 
hardware para navegadores” y protocolos de comu- 
nicación. Entonces se llevan a cabo pruebas para des- 
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cubrir los errores asociados con todas y cada una de 
las configuraciones posibles. 


. La WebAppse comprueba con una población de usua- 
riosfinales controlada y monitorizada. Se selecciona 
un grupo de usuarios que abarque todos los roles posi- 
bles de usuarios. La WebApp se pone en práctica con 
estos usuarios y se evalúan los resultados de su inte- 
racción con el sistema para ver los errores de conte- 
nido y de navegación, los intereses en usabilidad, 
compatibilidad, fiabilidad y rendimiento de la WebApp. 


Dado que muchas WebApps están en constante evo- 
lución, el proceso de comprobación es una actividad 
continua, dirigida por un personal de apoyo a la Web 
que utiliza pruebas de regresión derivadas de pruebas 
desarrolladas cuando se creó la WebApp. 


Dada la inmediatez de las WebApps, sería razonable 
preguntarse: ¿necesito realmente invertir tiempo esfor- 
zándome con la WebApp? ¿no debería dejarse que la 
WebApp evolucionarade forma natural, con poca o nin- 
guna gestión explícita? Muchos diseñadores de Webs 
optarían por gestionar poco o nada, pero eso no hace 
que estén en lo cierto. 

La ingeniería Web es una actividad técnica com- 
plicada. Hay muchas personas implicadas, y a menu- 
do trabajando en paralelo. La combinación de tareas 
técnicas y no técnicas que deben de tener lugar (a tiem- 
po y dentro del presupuesto) para producir una 
WebApp de alta calidad representa un reto para cual- 
quier grupo desprofesionales. Con el fin de evitar cual- 
quier confusión, frustración y fallo, se deberá poner 
en acción una planificación, tener en cuenta los ries- 
gos, establecer y rastrear una planificación temporal 
y definir los controles. Estas son las actividades clave 
que constituyen lo que se conoce como gestión de pro- 


yectos. 


Las actividodes asociados con la gestión de proyectos 
de software se estudian enla Porte Segunda 
de este libro. 


29.7.1. El equipo de IWEB 


La creación de una buena aplicación Web exige un amplio 
abanico de conocimientos. Tilley y Huang [TIL99] se 
enfrentan a este tema cuando afirman: «Hay muchos 
aspectos diferentes en relación con el softwarede aplica- 
ciones [Web] debido al resurgimiento del renacentista, 
aquel que se encuentracómodo trabajando en varias dis- 


7 Los navegadores son excelentes para implementar sus propias inter- 
pretaciones«estándar» ligeramente diferentes de HTML y Javascript. 
Para un estudio de temas de compatibilidad, véase www,browser- 
caps.com. 
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ciplinas...» Aun cuando los autores están absolutamente 
en lo cierto, los «renacentistas» no disponen de muchas 
provisiones, y dado las exigencias asociadas a los pro- 
yectos importantes de desarrollo de WebApps, el conjun- 
to de conocimientos diversos necesario podrá distribuirse 
incluso mejor dentro del equipo de IWeb. 


Los equipos de IWeb pueden organizarse de forma 
muy similar a como se organizan los equipos de softwa- 
re del Capítulo 3. Sin embargo, pueden existir diferen- 
cias entre los participantes y sus roles. Entre los muchos 
conocimientos que deben distribuirse por los miembros 
del equipo IWeb se encuentranlos siguientes: ingeniería 
del software basada en componentes, realización de redes, 
diseño arquitectónico y de navegación, lenguajes y están- 
dares de Intemet, diseño de interfacespara personas, dise- 
ño gráfico, disposición del contenido y pruebas de las 
WebApps. Los roles' siguientes deberán ser distribuidos 
entre los miembros del equipo IWeb: 

¿Qué papeles juegan 


$ las personas que forman 
parte del equipo de IWeb? 


Desarrolladores y proveedores de contenido.Dado 
que las WebApps son controladas inherentemente por 
el contenido, el papel de los miembros del equipo IWeb 
se centra en la generación y/o recolección del conteni- 


8 Estos roles se han adaptado de Harsen y sus colaboradores [HAN99]. 
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do. Retomando la idea de que el contenido abarca un 
amplio abanico de objetos de datos, los diseñadores y 
proveedores del contenido pueden proceder de diver- 
sos planos de fondo (no de software). Por ejemplo, el 
personal de ventas o de marketing puede proporcionar 
información de productos e imágenes gráficas: los pro- 
ductores de medios pueden proporcionarimagen y soni- 
do; los diseñadores gráficos pueden proporcionar diseños 
para composiciones gráficas y contenidos estéticos; los 
redactores publicitarios pueden proporcionar conteni- 
do basado en texto. Además, existe la posibilidad de 
necesitar personal de investigación que encuentre y dé 
formato al contenido externo y lo ubique y referencie 
dentro de la WebApp. 


Editores de Web. El contenidotan diverso generado 
por los desarrolladores y proveedores de contenido debe- 
rá organizarse e incluirse dentro de la WebApp. Además, 
alguien deberá actuar como conexión entre el personal 
técnico que diseña la WebApp y los diseñadores y pro- 
veedores del contenido. Esta función la lleva a cabo el 
editor de Web, quien deberá entender la tecnología tan- 
to del contenido como de la WebApp en donde se inclu- 
ye el lenguaje HTML (o ampliaciones de generaciones 
posteriores, tal como XML), la funcionalidad de bases 
de datos y guiones, y la navegación global del sitio Web. 


Ingeniero de Web. Un ingeniero Web cada vez se 
involucra más con la gran cantidad de actividades del 
desarrollo de una WebApp entre las que se incluyen la 
obtención de requisitos, modelado de análisis, diseño 
arquitectónico, de navegación y de interfaces, imple- 
mentación de la WebApp y pruebas. El ingeniero de Web 
también deberá conocer a fondo las tecnologías de com- 
ponentes, las arquitecturas cliente/servidor, HTML/XML, 
y las tecnologías de bases de datos; y deberá tener cono- 
cimiento del trabajo con conceptos de multimedia, pla- 
taformas de hardware/software, seguridad de redes y 
temas de soporte a los sitios Web. 


Especialistas de soporte. Este papel se asigna a la per- 
sona (personas) que tiene la responsabilidad de continuar 
dando soporte a la WebApp. Dado que las WebApps están 
en constanteevolución, el especialista de soportees el res- 
ponsable de las correcciones, adaptaciones y mejoras del 
sitio Web, donde se incluyen actualizaciones del conteni- 
do, implementación de productos y formularios nuevos, 
y cambios del patrón de navegación. 


Administrador. Se suele llamar Web master, y es el 
responsable del funcionamiento diario de la WebApp, 
en donde se incluye: 


2 Se recomienda que lectores no familiarizados con los conceptos 
básicos de gestión de proyectos revisen en este momento el Capí- 
tulo 3. 


» el desarrollo e implementación de normas para el 
funcionamiento de la WebApp; 

+ el establecimiento de los procedimientos de soporte 
y realimentación; 

+ los derechos de acceso y seguridad de la implemen- 
tación; 

+ la medición y análisis del tráfico del sitio Web; 


» la coordinación de los procedimientos de control de 
cambios (Sección 29.7.3); 


+ la coordinación con especialistas de soporte. 


El administrador también puede estar involucrado 
en las actividades técnicas realizadas por los ingenie- 
ros de Web y por los especialistas de soporte. 


29.7.2. Gestión del proyecto 


En la Parte Segunda de este libro se tuvieron en consi- 
deración todas y cada una de las actividades global- 
mente llamadas gestión de proyectos'. Las métricas de 
procesos y proyectos, la planificación de proyectos (y 
estimación), el análisis y gestión de riesgos, la planifi- 
cación temporal y el rastreo, SQA y CGS, se estudia- 
ron en detalle. En teoría, la mayoría de las actividades 
de gestión de proyectos, si no todas, estudiadas en capí- 
tulos anteriores, se aplican a los proyectos de IWeb. Pero 
en la práctica, el enfoque de IWeb para la gestión de 
proyectos es considerablemente diferente. 

En primer lugar, se subcontrata un porcentaje sus- 
tancial'" de WebApps a proveedores que (supuesta- 
mente) son especialistas en el desarrollo de sistemas y 
aplicaciones basados en Web. En tales casos, un nego- 
cio (el cliente) solicita un precio fijo para el desarrollo 
de una WebApp a uno o más proveeddtes, evalúa los 
precios de los candidatos y selecciona un proveedor para 
hacer el trabajo. Pero, ¿qué es lo que busca la organi- 
zación contratista?, ¿cómo se determina la competen- 
cia de un proveedor de WebApps?, ¿cómo se puede 
saber si un precio es razonable?, ¿qué grado de planifi- 
cación, programación temporal, y valoración de riesgos 
se puede esperar a medida que una organización (y su 
subconstratista) se va embarcando en un desarrollo 
importante de WebApps? 

En segundo lugar, el desarrollo de WebApps es una 
área de aplicación relativamente nueva por tanto se pue- 
den utilizar pocos datos para la estimación. Hasta la 
fecha, no se ha publicado virtualmente ninguna métri- 
ca de IWeb. De hecho, tampoco han surgido muchos 
estudios sobre lo que esas métricas podrían ser. Por tan- 
to, la estimación es puramente cualitativa —basadaen 


10 Aun cuando los datos de industria fiables son dificiles de encon- 
trar, es seguro decir que este porcentaje es considerablemente mayor 
que el que se encuentra en el trabajo del software convencional. 
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experiencias anteriores con proyectos similares —. Pero 
casi todas las WebApps tienen que ser innovadoras 
—ofreciendo algo nuevo y diferente a aquellos que la 
utilizan —. De aquí que la estimación experimental, aun- 
que sea Útil, está abierta a errores considerables. Por 
consiguiente, ¿cómo se derivan estimaciones fiables?, 
¿con qué grado de seguridad pueden cumplirse los pro- 
gramas temporales definidos? 

En tercer lugar, el análisis de riesgos y la programa- 
ción temporal se predican bajo un entendimiento claro 
del ámbito del proyecto. Y sin embargo, la característi- 
ca de «evolución continua» tratada en la Sección 29.1 
sugiere que el ámbito de la WebApp sea fluido. ¿Cómo 
pueden controlar los costes la organización contratista 
y el proveedor subcontratado?, y ¿cómo pueden plani- 
ficar el momento en que es probable que los requisitos 
cambien drásticamente a lo largo del proyecto?, ¿cómo 
se puede controlar el cambio del ámbito?, y lo que es 
más importante, dado su naturaleza ¿deberán contro- 
larse los sistemas y aplicaciones basados en Web ? 

Llegado a este punto de gestión de proyectos para 
WebApps, las preguntas que se han formulado por las 
diferencias destacadas anteriormente no son fáciles de 
responder. Sin embargo, merece la pena tener en con- 
sideración una serie de líneas generales. 


Inicio de un proyecto. Aun cuando la subcontrata- 
ción sea la estrategia elegida para el desarrollo de 
WebApps, una organización deberá realizar una serie 
de tareas antes de buscar el proveedor de subcontrata- 
ción para hacer el trabajo. 


1. Muchas de las actividades de análisis tratadas en la 
Sección 29.3 se deberán realizar internamente. Se 
identifica el público de la WebApp; se confecciona un 
listado de aquellos con intereses internos en la 
WebApp; y se definen y revisan las metas globales de 
la WebApp; se especifica tanto la información como 
los servicios que se van a proporcionaren la WebApp; 
se destacan los sitios Web rivales, y se definen las 
«medidas» cuantitativas y cualitativas para obtener 


consejo pora los constructores 

Establecer los requisitos 
fomente. 2. Conseguir 

.. 3. Utilizar proveedores 

do, 4. Construir y ampliar 

pos evolutivas. 5. Tener 

jo sistemática odecuada 

permitir olgún grado 

aparezcan errores. 
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una WebApp con éxito. Esta información deberá de 
documentarse en una especificación del producto. 


. Se deberá desarrollar internamente un diseño apro- 
ximado de la WebApp. Obviamente una persona 
experta en el desarrollode WebApps creará un diseño 
completo, pero puede ahorrar tiempo y dinero iden- 
tificando el aspecto e interacción general de la 
WebApp para el proveedor de subcontratación (esto 
siempre puede modificarse durante las etapas preli- 
minares del proyecto). El diseño deberáincluirla indi- 
cación del proceso interactivo que se va a llevar a 
cabo (por ejemplo, formularios, entrada de pedidos). 


. Se deberá desarrollaruna planificación temporal apro- 
ximada del proyecto, incluyendo no solo lasfechas 
finales de entrega, sino también lasfechas hito (signi- 
ficativas). Los hitos deberán adjuntarse a las versiones 
de entrega posibles a medida que avanza el proyecto. 


. Se deberá identificar el grado de supervisión e inte- 
racción del contratista con el proveedor. Deberá 
incluirse el nombre del contacto del proveedor y la 
identificación de la responsabilidad y autoridad del 
contacto, la definición de los puntos de revisión de 
calidad a medida que el desarrollo va avanzando, y 
la responsabilidad de los proveedores en relación con 
la comunicación entre organizaciones. 


Toda la información desarrollada en los pasos ante- 


riores deberá de organizarse en una solicitud de opcio- 
nes que se transmite a los proveedores candidatos”. 


1 por cacahuetes, 


Selección entre los proveedores de subcontrata- 
ción candidatos. En los últimos años han surgido miles 
de compañías de «diseño Web» para ayudar a las empre- 
sas a establecer una presencia y/o implicación Web en 
el comercio electrónico. Muchas han llegado a tener 
adicción por el proceso IWeb, mientras que otras muchas 
se asemejan a los intrusos informáticos (hackers).Con 
objeto de seleccionar el desarrollador de Web candida- 
to, el contratistadeberá llevar a cabo una diligencia obli- 
gada: (1) entrevistar a los clientes antiguos para 
determinar la profesionalidad del proveedor de Web, la 
habilidad de cumplirlos compromisos de horarios y cos- 
tes, y la habilidad de comunicarseeficazmente; (2) deter- 
minar el nombre del ingenierojefe de Web del proveedor 
de proyectos anterior con éxito (y después cerciorarse 
de que esta persona se vea obligada mediante contrato 
a su implicación en el proyecto), y (3) examinar cuida- 
dosamente las muestras de trabajo del proveedor simi- 


1 Si el trabajo de desarrollo de la WebApp es dirigida por un grupo 
interno, nada cambia. El proyecto se inicia de la misma manera. 
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lares en aspecto e interacción (y en área de negocios) a 
la WebApp que se va a contratar. Antes incluso de que 
se vaya a establecer la oferta, una reunión cara a cara 
puede proporcionar una buena impresión para que el 
contratista y el proveedor conecten bien. 


Evaluación de la validez de las ofertas de precios 
y de la fiabilidad de las estimaciones.Dado que exis- 
ten muy pocos datos históricos y el ámbito de las 
WebAppses notoriamente fluido, la estimación es inhe- 
rentemente arriesgada. Por esta razón algunos provee- 
dores incorporarán márgenes sustanciales de seguridad 
en las ofertas de precios de un proyecto. Evidentemen- 
te esto es comprensible y adecuado. La pregunta no es 
si tenemos la mejor solución para nuestra inversión, sino 
la serie de preguntas que se muestran a continuación: 
¿Es el coste acordado una buena oferta para propor- 
cionar un beneficio directo o indirecto sobre la inver- 
sión y justificar así el proyecto? 
¿Es el proveedor de la oferta una muestra clara de la 
profesionalidad y experiencia requeridos? 


Si la respuesta es «sí», el precio ofertado es justo. 


El grado de gestión del proyecto que se puede espe- 
rar o realizar. La formalidad asociada con las tareas de 
gestión del proyecto (llevadas a cabo tanto por el provee- 
dor como por el contratista) es directamente proporcional 
al tamaño, coste y complejidad de la WebApp. Para pro- 
yectos complejos y grandes deberá desarrollarse una pla- 
nificación que defina las tareas del trabajo, los puntos de 
comprobación, los productos de trabajo de ingeniería, los 
puntos de revisión del cliente y los hitos importantes. El 
proveedor y el contratista deberán evaluar el riesgo en 
conjunto, y desarrollar los planes de mitigar, monitorizar 
y gestionaresos riesgos considerados como importantes. 
Los mecanismos para la seguridad de calidad y el control 
de cambios se deberán definir explícitamente al escribir- 
se. Y tendrán que establecerse métodos de comunicación 
entre el contratista y el proveedor. 


Evaluación de la planificación temporal del desa- 
rrollo. Dado que las planificacionesde desarrollo de las 
WebApps abarcan un período de tiempo relativamente 
corto (normalmente menos de un mes o dos), la plani- 
ficación de desarrollo deberá tener un alto grado de gra- 
nularidad. Es decir, las tareas del trabajo y los hitos 
menores se tendrán que planificar día a día. Esta gra- 
nularidad permite que el contratista y el proveedorreco- 
nozcan la reducción del tiempo de planificación antes 
de que amenace la fecha de finalización. 


Gestión del ámbito. Dado que es muy probable que 
el ámbito cambie a medida que avanza el proyecto de la 
WebApp, el modelo de proceso deberá ser incremental 
(Capítulo 2). Esto permite que el equipo de desarrollo 
«congele» el ámbito para poder crear una nueva versión 
operativa de la WebApp. El incremento siguiente puede 
afrontar los cambios de ámbito sugeridos por una revi- 
sión del incremento precedente, pero una vez que comien- 
za el incremento, el ámbito se congela de nuevo 
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«temporalmente».Este enfoque hace posible que el equi- 
po de la WebApp trabaje sin tener que aceptaruna corrien- 
te continua de cambios, pero reconociendo la característica 
de evolución continua de la mayoría de las WebApps. 

Las líneas generales sugeridas anteriormente no pre- 
tenden ser un recetario a prueba de tontos para WebApps 
puntuales y con una producción a un coste bajo. Sin 
embargo, ayudarán tanto al contratista como al provee- 
dor a iniciar el trabajo suavemente con unos conoci- 
mientos mínimos. 


29.7.3. Problemas GCS para la IWEb 


Durante la última década, las WebApps han evolucio- 
nado y han pasado de utilizar dispositivos informales 
para la difusión de información a utilizar sitios sofisti- 
cados para el comercio electrónico. A medida que las 
WebApps van creciendo en importancia para la super- 
vivencia y el crecimiento de los negocios, también cre- 
ce el control de la configuración. ¿Por qué? Porque sin 
controles eficaces cualquier cambio inadecuado en una 
WebApp (recordemos que la inmediatez y la evolución 
continua son los atributos dominantes de muchas 
WebApps) puede conducir a: (1) una ubicación no auto- 
rizada de la información del producto nuevo; (2) una 
funcionalidad errónea y pobremente comprobada que 
frustra a los visitantes del sitio Web; (3) agujeros de 
seguridad que ponen en peligro a los sistemas internos 
de las compañías, y otras consecuencias económica- 
mente desagradables e incluso desastrosas. 


más eficaz de enfrentarse 
es oyudar a crearlo. 


Se pueden aplicar las estrategias generales para la 
gestión de la configuración del software (GCS) descri- 
tas en el Capítulo 9, pero las tácticas y herramientas 
deberán adaptarse y ajustarse a la naturaleza única de 
las WebApps. Cuando se desarrollan tácticas para la 
gestión de configuración de las WebApps, deberán tener- 
se en consideración cuatro temas [DAR99]: el conteni- 
do, las personas, la escalabilidad y la política. 

Contenido. Una WebApp normal contiene una gran 
cantidad de contenido —texto, gráficos, applets, guiones, 
archivos de sonido y vídeo, elementos activos de págl- 
nas, tablas, corrientes de datos y muchos más— El reto 
es organizareste mar de contenido en un conjunto razo- 
nable de objetos de configuración (Capítulo 9), y enton- 
ces establecerlos mecanismos de control de configuración 
adecuados para estos objetos. Un enfoque será modelar 
el contenido de la WebApp mediante la utilización de téc- 
nicas convencionales de modelado de datos (Capítulo 
11), adjuntando un conjunto de propiedades especializa- 
das a cada objeto. La naturaleza estática y dinámica de 
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cada objeto y la longevidad proyectada (por ejemplo, 
existencia temporal y fija, o un objeto permanente) son 
ejemplos de las propiedades necesarias para establecer 
un enfoque GCS eficaz. Por ejemplo, si se cambia un 
objeto de contenidocada hora, se dice que tiene una lon- 
gevidad temporal. Los mecanismos de control de este 
objeto serán diferentes (menos formales) de los que se 
aplican a un componente de formularios (objeto perma- 


nente). 
Consuof) 


E esencial controlar el cambio durante los proyectos 
Web, aun cuando puede hacerse de formo exagerada. 
Emplece por los procedimientos de control de cambio 

de relativa informalidad (Capítulo 9). lo meto inicial será 
evitarlos efectos de trinquete en cambios incontrolados. 


Personas. Dado que un porcentaje significativo del 
desarrollo de las WebApps continúarealizándose depen- 
diendo del caso, cualquier persona que esté implicada 
en la WebApp puede (y a menudo lo hace) crear el con- 
tenido. Muchos creadores de contenido no tienen ante- 
cedentes en ingeniería del software y no tienen ningún 
conocimiento de la necesidad de una gestión de confi- 
guración. La aplicación crece y cambia de forma incon- 
trolada. 


Escalabilidad. Las técnicas y controles aplicados a 
una WebApp pequeña no tienen buena escalabilidad. 
No es muy común que una WebApp sencilla crezca sig- 
nificativamente cuando se implementan las intercone- 
xiones que existen dentro de los sistemas de 
información, bases de datos, almacenes de datos y pasa- 
relas de portales. A medida que crece el tamaño y la 
complejidad, los pequeños cambios pueden tener efec- 
tos inalcanzables y no intencionados que pueden ser 
problemáticos. Por tanto, el rigor de los mecanismos de 
control de la configuración deberán ser directamente 
proporcionales a la escalabilidad de la aplicación. 

Política. ¿Quién es el propietario de una WebApp? 
Esta pregunta se argumenta en compañías grandes y 
pequeñas, y la respuesta tiene un impacto significativo 


Se puede argumentar que el impacto de los sistemas y 
aplicaciones basados en Web es el acontecimiento más 
significativo en la historia de la informática. A medida 
que las WebApps crecen en importancia, el enfoque de 
ingeniería de Web disciplinado ha empezado a evolu- 
cionar — basadoen principios, conceptos, procesos y 
métodos que se han desarrollado para la ingeniería del 
software —. 

Las WebApps son diferentes de otras categorías de 
softwareinformático. Son intensivas de red, están gober- 
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en las actividades de gestión y control asociadas con la 
IWeb. En algunos casos los diseñadores de WebApps 
se encuentran fuera de la organización TI, dificultando 
posiblemente la comunicación. Para ayudar a entender 
la política asociada a IWeb, Lt [DAR99] sugiere las 
siguientes preguntas: ¿quién asume la responsabilidad 
de la información en el sitio Web? ¿quién asegura que 
los procesos de control de calidad se han llevado a cabo 
antes de publicar la información en el sitio Web? ¿quién 
es el responsable de hacer los cambios? ¿quién asume 
el coste del cambio? Las respuestas ayudarán a deter- 
minar qué personas dentro de la organización deberán 
adoptar un proceso de gestión de configuración para las 
WebApps. 

La gestión de configuración para la IWeb está toda- 
vía en su infancia. Un proceso convencional de GCS 
puede resultar demasiadopesado y torpe. La gran mayo- 
ría de las herramientas GCS no tienen las característi- 
cas que permiten adaptarse fácilmente a la IWeb. Entre 
los temas que quedan por tratar se encuentran los 
siguientes [DAR99]: 


creación de un proceso de gestión de configuración 
que sea lo suficientemente hábil como para aceptar la 
inmediatez y la evolución continua de las WebApps; 


aplicación de mejores conceptos y herramientas de 
gestión de configuración para aquellos que desarro- 
llan y no están familiarizados con la tecnología; 
suministro del soporte a los equipos de desarrollo de 
WebApps distribuidos; 

suministro de control en un entorno de cuasipubli- 
cación, donde el contenido cambia de forma casi con- 
tinua; 

consecución de la granularidad necesaria para con- 
trolar una gran cantidad de objetos de configuración; 
incorporación de la funcionalidad de gestión de con- 
figuración en las herramientas IWeb existentes; 
gestión de cambios en objetos que contienen enla- 
ces con otros objetos. 

Estos y otrostemas deberán afrontarse antes de que se 
disponga una gestión de configuración eficaz para la IWeb, 


nadas por el contenido y están en continua evolución. La 
inmediatez que conduce a su desarrollo, la necesidad pri- 
mordial de seguridad al funcionar, y la demanda de esté- 
tica y la entrega del contenido funcional son otros factores 
diferenciadores. Durante el desarrollode la WebApp hay 
tres tecnologías que se integran con otras de ingeniería 
del software convencional; desarrollo basado en compo- 
nentes, seguridad y lenguajes de notas estándar. 

El proceso de ingenieríade Web comienza con la for- 
mulación —una actividad que identifica las metas y los 
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objetivos de la WebApp—. La planificación estima el 
coste global del proyecto, evalúa los riesgos asociados 
con el esfuerzo del desarrollo y define una programación 
temporal del desarrollo. El análisis establece requisitos 
técnicos e identificalos objetos del contenidoque se incor- 
porarán en la WebApp. La actividad de ingenieríaincor- 
pora dos tareas paralelas: diseño del contenido y diseño 
técnico. La generación de páginas es una actividad de 
construcción que hace un uso extenso de herramientas 
automatizadas para la creación de WebApps, y la com- 


probación ejercita la navegación de la WebApp, inten- 
tando descubrir errores en la función y el contenido, y 
asegurando mientras tanto que la WebApp funcione 
correctamente en diferentes entornos. La ingeniería de 
Web hace uso de un modelo de proceso iterativo e incre- 
mental porque la línea temporal del desarrollo para la 
WebApp es muy corta. Las actividades protectoras apli- 
cadas durante el trabajo de la ingeniería del software 
—-SQA, GCS, gestión de proyectos — se aplican a todos 
los proyectos de ingeniería de Web. 


[ATK97] 
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29.1. ¿Existen otros atributos genéricos que diferencien a las 
WebApps de otras aplicaciones de software? Enumere 2 03. 


29.2. ¿Cómo sejuzga la calidad de un sitio Web? Confeccio- 
ne una lista de 10 atributos de calidad prioritarios que consi- 
dere más importantes. 


29.3. Realice una pequeña investigación y realice un trabajo 
de 2 3 páginas que resuma una de las tres tecnologías que 
se destacaron en la Sección 29.1.2, 


29.4. Utilizando un sitio Web real como ejemplo, ilustre las 
diferentes manifestaciones del «contenido» de la WebApp. 


29.5. Responda a las tres preguntas de formulación para un 
sitio Web con el que esté familiarizado. Desarrolle una afir- 
mación de ámbito para el sitio Web. 


29.6. Desarrolle un conjunto de perfiles para HogarSegu- 
rolnc.com o un sitio Web asignado por su profesor. 


29.7. Desarrolle una lista completa de metas informativas y 
aplicables para HogarSeguroInc.com o un sitio Web asigna- 
do por su profesor. 


29.8. Elabore un conjunto de casos de uso para HogarSegu- 
rolnc.com o un sitio Web asignado por su profesor. 


29.9. ¿En qué difiere el análisis del contenido del análisis fun- 
cional y de interacción? 
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29.10. Realice un análisis del contenido para HogarSegu- 
rolnc.com o para un sitio Web asignado por su profesor. 


29.11. Sugiera tres «reglas de oro» que servirán como guía en 
el diseño de WebApps. 


29.12. ¿En qué difiere una configuración de diseño WebApp 
de una plantilla? 


29.13. Seleccione un sitio Web con el que esté familiarizado 
y desarrolle un diseño arquitectónico razonablemente com- 
pleto para el sitio. ¿Qué estructura arquitectónica seleccionó 
el diseñador del sitio? 


29.14. Haga una investigación breve y escriba 2 Ó 3 páginas 
que resuman el trabajo actual en las configuraciones de dise- 
ño de las WebApps. 


29,15. Desarrolle un diseño arquitectónico para HogarSegu- 
rolnc.com o para un sitio Web asignado por su instructor. 


29.16. Utilizando un sitio Web real como ejemplo, desarrolle 
una crítica de su interfaz de usuario y haga una recomenda- 
ción que lo mejore. 


29.17. Describala manera en que una gestión de proyecto para 
sistemas y aplicaciones basados en Web difieren de la gestión 
de proyecto para el software convencional. ¿En qué se ase- 
meja? 


Durante los últimos años se han publicado cientos de libros 
que tratan uno o más temas de ingeniería de Web, aunque 
relativamente pocos tratan todos losaspectos. Lowe y Hall 
(Hypertextand the Web:An Engineering Approach, Wiley, 
1999), y Powell [POW98] abarcan razonablemente estos 
temas. Norris, West y Warson (MediaEngineering: A Quide 
to Developing Information Products, Wiley, 1997), Navarro 
y Khan (Effective Web Design: Master the Essentials, Sybex, 
1998), Fleming y Koman (WebNavigation: Designing the 
User Experience, O'Reilly $ Associates, 1998), y Sano 
[SAN96] también abarcan aspectos importantes del proceso 
de ingeniería. 

Además de [LYN99], [DIN98] y [SPO98], los siguientes 
libros proporcionan una guía útil para los aspectos del dise- 
ño de WebApps tanto técnicos como no: 

Baumgardt, M., Creative Web Design: Tips and Tricks 
Step by Step, Springer Verlag, 1998. 

Donnelly, D. et al., Cutting Edge Design: The Next Gene- 
ration, Rockport Publishing, 1998. 

Holzschlag, M.E., Webby Design: The Complete Guide, 
Sybex, 1998. 

Niederst, J., y R. Koman, WebDesign in a Nutshell: A 
Desktop Quick Reference, O”Reilly £ Associates, 1998. 

Weinman, L., y R. Prirouz, Click Here: Web Communi- 
cation Design, New Riders Publishing, 1997. 
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Menasce y Almeida (Capacity Planningfor Web Perfor- 
mance: Metrics, Models, and Methods, Prentice-Hall, 1998) 
tratan la valoración cuantitativa del rendimiento de las 
WepApps. Amoroso (Intrusion Detection: An Introduction to 
Internet Surveillance, Correlation, Trace Back, Traps, and 
Response, Intrusion.Net Books, 1999) proporciona una guía 
detallada para los ingenieros de Web que están especializa- 
dos en temas de seguridad. Umar (Application(Re)Enginee- 
ring: Building Web-Based Applications and Dealing With 
Legacies, Prentice-Hall, 1997)estudia estrategias para la trans- 
formación (reingeniería) de sistemas anteriores en aplicacio- 
nes basadas en Web. Mosley (ClientSewer Software Testing 
on the Desk Top and the Web, Prentice-Hall, 1999) ha escri- 
to uno de los mejores libros que estudian los temas de com- 
probación asociados con WebApps. 

Haggard (Survival Guide to Web Site Developrnent, 
Microsoft Press, 1998) y Siegel (Secrets of Successful Web 
Sites: Project Management on the World Wide Web, Hay- 
den Books, 1997) proporcionan una guía para el gestor que 
debe de controlar y hacer un seguimiento del desarrollo de 
WebApps. 

Una amplia variedad de fuentes de información sobre inge- 
niería de Web está disponible en Internet. Una lista amplia y 
actualizada de referencias en sitios (páginas) web se puede 
obtener en http:/www.pressman5.com. 
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REINGENIERÍA 


N un artículo de gran importancia escrito para la Harvard Business Review, Michael 
Hammer [HAMO9O0O] sentaba las bases para una revolución del pensamiento administrati- 
vo acerca de los procesos y computación de los negocios: 


Ha llegado el momento de dejar de pavimentar los senderos para vacas. En lugar de incrustar unos pro- 
cesos anticuados en silicio y en software, deberíamos eliminarlos y volver a empezar. Tenemos que reha- 
cer la ingeniería de nuestros negocios: hay que utilizar la potencia de la tecnología de'la información moderna 
para rediseñar de forma radical nuestros procesos de negocios, y lograr asíunas mejoras drásticas de su ren- 
dimiento. 

Todas las compañías funcionan de acuerdo con una gran cantidad de reglas no escritas... La reingenie- 
ría intenta apartarse de las viejas reglas acerca de la forma en que se organizan y desarrollan nuestros ne- 
gocios. 


Al igual que todas las revoluciones, la llamada a las armas de Hammer ha dado lugar a cam- 
bios tanto positivos como negativos. Algunas compañías han hecho un esfuerzo legítimo, en 
rehacer su ingeniería, y los resultados han mejorado su competitividad. Otras se han basado 
únicamente en reducir las dimensiones y hacer subcontratas (en lugar de rehacer su reingenie- 
ría) para mejorar sus beneficios. Y como resultado se obtuvieron organizaciones reducidas con 
pocas probabilidades de crecer en un futuro [DEM9S5], 

Durante la primera década del siglo veintiuno, el bombo publicitario asociado a la reinge- 
niería ha decaído, pero el proceso en sí continúa en compañías grandes y pequeñas. La unión 
de la reingeniería con la ingeniería del software se encuentra en una «revisión del sistema». 


VISTAZO RÁPIDO 


¿Qué es? Tenga en consideración cual- ¿Por qué esimportemte? Vivimosen un los programas existentes que exhiben 


quier producto de tecnología que haya 
adquirido. Lo ve con regularidad, pero 
está envejeciendo. Se rompe con fre- 
cuencia, tarda en repararse y ya no 
representa la última tecnología. ¿Qué 
se puede hacer? Si el producto es de 
hardware, probablemente lo tirará y se 
comprará uno nuevo. Pero si es un soft- 
ware personalizado, no dispondrá la 
opción de tirarlo. Necesitará recons- 
truirlo. Creará un productocon una fun- 
cionalidad nueva, un mejor rendimiento 
y fiabilidad, y un mantenimiento mejo- 
rado. Eso es lo que llamamos reinge- 
niería. 


¿Quién lo hace? A nivel de negocio, la 


reingeniería es ejercida por especia- 
listas de negocio (frecuentemente 
empresas de consultoría). A nivel de 
software, la reingeniería es ejecutada 
por ingenieros del software. 


mundoen constantecambio. Las deman- 
das de funciones de negocios y de tec- 
nología de informaciónque las soportan 
están cambiando a un ritmo que impo- 
ne mucha presión competitiva en todas 
las organizaciones comerciales. Tanto 
los negocios comoel softwareque sopor- 
tan (oes)el negocio deberán diseñarse 
una vez más para mantener el ritmo. 


¿Cuáles son los pasos? La reingenieria 


de procesosde negocios(RPN) definelas 
metas comerciales, identifica y evalúa 
los procesos de negocios existentes, y 
crea procesos comercialesrevisados que 
mejoran las metas actuales. El proceso 
de reingeniería del software acompaña 
el análisis de inventarios, la estructura- 
ción de documentoc. laingenieríainver- 
sa, la reestructuración de datos y la 
ingeniería avanzada. El objetivode estas 
actividadesescrearversionesnuevasde 


una mantenibilidad de mayor calidad. 


¿Cuál es el producto obtenido? Son 


varios los productos que se elaboran 
(porejemplo,modelos análisis, modelos 
de diseño, procedimientos de pruebas). 
El resultado final es un proceso de rein- 
geniería de negocios y/o el software de 
reingeniería que lo soporta. 


¿Cómo puedo esta seguro de que lo 


he hecho correctamente?Utilizan- 
dolas mismas prácticas que se aplican 
en todos los procesos de ingeniería del 
software —las revisiones técnicas for- 
males evalúan los modelos de análisis 
y de diseños, las revisiones especializa- 
das tienen en consideración la capaci- 
dad de aplicación comercial y la 
compatibilidad, y la comprobación se 
aplica para descubrir los errores en el 
contenido, en la funcionalidad y en la 
interoperabilidad. 


El software suele ser la realización de las reglas de negocio que describe Hammer. A medida que 
las reglas cambian, el software también tiene que cambiar. En la actualidad, existen compañías impor- 
tantes que poseen decenas de miles de programas de computadora que prestan apoyo a las «viejas 
reglas del negocio». Cuando los administradores trabajan para modificar estas reglas y lograr así una 
mayor efectividad y competitividad,el software seguirá el mismo ritmo. En algunos casos, esto impli- 
ca la creación de sistemas nuevos e importantes basados en computadora'. Pero en muchos otros, esto 
implica la modificación y/o reconstrucción de las aplicaciones existentes. 


! Los sistemas y aplicaciones basados en Web estudiados en el Capítulo 29 son ejemplos contemporáneos. 
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En este capítulo se examina la reingeniería de forma descendente, comenzando por una visión general de la reingenie- 
ría de procesos de negocio y pasando entonces a una discusión más detallada de las actividades técnicas que se producen 


cuando se efectúa una reingeniería del software. 


La Reingeniería de procesos de negocio, RPN (Busi- 
ness Process Reingineering, BPR?) va más allá del ámbi- 
to de las tecnologías de la información y de la ingeniería 
del software. Entre las muchas definiciones (la mayo- 
ría de ellas, algo abstractas) que se han sugerido para la 
RPN, se cuenta con una publicada en la revista Fortu- 
ne [STE93]: «. ..la búsqueda e implementación de cam- 
bios radicales en el proceso de negocios para lograr un 
avance significativo». Ahora bien ¿cómo se efectúa la 
búsqueda, y cómo se lleva a cabo la implementación? 
O lo que es más importante, ¿cómo podemos estar segu- 
ros de que el «cambio radical» que se sugiere va a dar 
lugar realmente a un «avance significativo» en lugar de 
conducimos a un caos organizativo? 


dd 

y > 
mañana con la idea de utilizar 
es verla vida paralizada. 


30.1.1. Procesos de negocios 


Un proceso de negocio es «un conjunto de tareas lógi- 
camente relacionadas que se llevan a cabo para obtener 
un determinado resultado de negocio» [DAV90]. Den- 
tro del proceso de negocio, se combinan las personas, 
los equipos, los recursos materiales y los procedimien- 
tos de negocio con objeto de producir un resultado con- 
creto. Entre los ejemplos de negocio se incluyen el 
diseño de un nuevo producto, la adquisición de servi- 
cios y suministros, la contratación de nuevos emplea- 
dos O el pago a proveedores. Cada una requiere un 
conjunto de tareas y se basa en diversos recursos den- 
tro del negocio. 

Cada proceso de negocio posee un cliente bien defi- 
nido —una persona o grupo que recibe el resultado (por 
ejemplo: una idea, un informe, un diseño, un produc- 
to)—. Además, los procesos de negocio cruzan los lími- 
tes organizativos. Requieren que distintos grupos de la 
organización participen en las «tareas lógicamente rela- 
cionadas» que definen el proceso. 

En el Capítulo 10se indicaba que todo sistema es en 
realidad una jerarquía de subsistemas. El negocio glo- 
bal se puede segmentar de la siguiente manera: 

El negocio 

sistemas de negocio 
proceso de negocio 


subprocesos de negocio 


2 BPR, en castellanoRPN 


Consuo o 


Como ingeniero delsoftware, el trabajo de reingenierío 
tienelugar en lo porte inferiorde lajerorquío. 

Sin embargo, asegúrese de que alguien hoyo pensado 
seriamente en el nivel anterior. Sino lo han hecho, 

su trabajo corre algún riesgo. 


Cada uno de los sistemas de negocios (también lla- 
madosfunción de negocios) están compuestos por uno 
o más procesos de negocio, y cada proceso de negocio 
está definido por un conjunto de subprocesos. 

La RPN se puede aplicar a cualquier nivel de lajerar- 
quía, pero a medida que se amplía el ámbito de la RPN 
(esto es, a medida que se asciende dentro de la jerarquía) 
los riesgos asociados a la RPN crecen de forma dramáti- 
ca. Por esta razón, la mayor parte de los esfuerzos de la 
RPN se centran en procesos o subprocesosindividuales. 


30.1,2, Principios de reingeniería de procesos 
de negocios 


En muchos aspectos, la RPN tiene un objetivo y un ámbi- 
to idéntico al proceso de la ingeniería de la información 
(Capítulo 10). Lo ideal sería que la RPN se produjera de 
forma descendente, comenzando por la identificación de 
los objetivos principales del negocio, y culminando con 
una especificación mucho más detallada de las tareas que 
definen un proceso específico de negocios. 

Hammer [HAM90] sugiere una serie de principios 
que nos guiarán por las actividades de la RPN cuando 
se comienza en el nivel superior (de negocios): 

Organización en torno a los resultados, no en torno a las 
tareas. Hay muchas compañías que poseen actividades de nego- 
cio compartimentadas,de tal modo que no existe una Única 
persona (u organización)que tenga la responsabilidad (oel con- 
trol) de un cierto resultado de negocio. En tales casos, resulta 
difícil determinar el estado del trabajo e incluso más difícil 
depurarlos problemas de proceso cuandoesto sucede. La RPN 
deberá diseñar procesos que eviten este problema. 

Hay que hacer que quienes utilicen la salida del proceso 
llevena cabo elproceso. El objetivo de esta recomendación es 
permitir que quienes necesitenlas salidas del negocio contro- 
len todas las variables que les permitan obtener esa salida de 
forma temporalmente adecuada. Cuanto menor sea el número 
de personas distintas implicadas en el proceso, más fácil será 
el camino hacia un resultado rápido. 


Referencia 


Poro encontrar uno extensa información 
sobre lo reingenierío de procesos de negocios 
visite la dirección www.brint.com /BPR.htm 
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Hay que incorporarel trabajo de procesamiento de infor- 
mación al trabajo real que produce la información pura. A 
medida que la TI se distribuye, es posible localizar la mayor 
parte del procesamiento de información en el seno de la orga- 
nización que produce los datos. Esto localiza el control, redu- 
ce el tiempo de comunicación y la potencia de computación se 
pone en manos de quienes tienen fuertes intereses en la infor- 
mación producida. 


Hay que manipular recursos geográficamente dispersos 
como si estuviesen centralizados. Las comunicaciones basa- 
das en computadoras se han sofisticado tanto que es posible 
situar grupos geográficamente dispersos en una misma «ofici- 
na virtual», Por ejemplo, en lugar de emplear tres turnos de 
ingeniería en una única localización, toda la compañía podrá 
tener un turno en Europa, un segundo turno en Norteaménca 
y un tercer turno en Asia. En todos los casos, los ingenierostra- 
bajarán durante el día y se comunicarán empleando redes de 
un elevado ancho de banda. 


pe 


como vemos lo existencia de algo 
nuevo, nos tranquilizamos. 


Hay que enlazar las actividadesparalelas en lugar de inte- 
grar sus resultados. Cuando se utilizan diferentes grupos de 
empleados para realizar tareas en paralelo, es esencial diseñar 
un proceso que exija una continuación en la comunicación y 
coordinación. En caso contrario, es seguro que se producirán 
problemas de integración. 


Hay que poner el punto de decisión en el lugar donde se 
efectúa el trabajo, e incorporar el control al proceso. Dentro 
de lajerga del diseño del software, esto sugiere una estructura 
organizativa más uniforme y con menos factorización. 


Hay que capturar los datos una sola vez, en el lugar don- 
de se producen. Los datos se deberán almacenar en computa- 
doras, de tal modo que una vez recopilados no sea necesario 
volver a introducirlos nunca. 


Todos y cada uno de los principios anteriores repre- 
sentan una visión «totalmente general» de la RPN. Una 
vez informados por estos principios, los planificadores de 
negocios y los diseñadores de procesos deberán empezar 
a procesar el nuevo diseño. En la sección siguiente, se 
examinará el proceso de RPN más detalladamente. 


30.1.3. Un modelo de RPN 


Al igual que la mayoría de las actividades de ingenie- 
na, la reingeniería de procesos de negocio es iterativa. 
Los objetivos de negocio, y los procesos que los logran, 
deberán adaptarse a un entorno de negocio cambiante. 
Por esta razón, no existe ni principio ni fin en la RPN 
—=s8 trata de un proceso evolutivo —. En la Figura 30.1 
se representa un modelo de reingeniería de procesos de 
negocio. Este modelo define seis actividades: 


Definición del negocio. Los objetivos de negocios 
se identifican en un contexto de cuatro controladores 
principales: reducción de costes, reducción de tiempos, 
mejora de calidad y desarrollo y potenciación del per- 
sonal. Los objetivos se pueden definir en el nivel de 
negocios O para un componente específico del negocio. 
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Identificación de procesos. En esta actividad se iden- 
tifican los procesos críticos para alcanzar los objetivos 
definidos en la definición del negocio, A continuación, 
pueden recibir prioridades en función de su importan- 
cia, necesidad de cambio, o cualquier otra forma que 
resulte adecuada para la actividad de reingeniería. 


Definición 
del negocio 


Refinamiento 
e instanciación kh 


Identificación 
de procesos 


Creación 
de prototipos 


Especificación 
y diseño 
de procesos 


Evaluación 
de procesos 


FIGURA 30.1. Un modelo de BPR. 


Evaluación de procesos. Los procesos existentes 
deberán analizarse y medirse exhaustivamente. Las 
tareas de procesos se identificarán; los costes y los tiem- 
pos consumidos por las tareas de proceso se anotarán 
cuidadosamente, y se aislarán los problemas de calidad 
y rendimiento. 


Especificación y diseño de procesos. Basándose en la 
informaciónobtenida durante las tres primeras actividades 
de la RPN, se prepararán casos prácticos (Capítulo 11)para 
cada uno de los procesos que se tengan que rediseñar. Den- 
tro del contexto de la RPN, los casos prácticos identifican 
un escenario que proporcionaresultados a un cliente. Con 
el uso de casos prácticos como especificacióndel proceso, 
se diseña un nuevo conjunto de tareas (que se ajustan a los 
principios indicadosen la Sección 30.2.1) para el proceso. 

Creación de prototipos. Es preciso construir un pro- 
totipo del proceso de negocios rediseñado antes de inte- 
grarlo por completo en el negocio. Esta actividad 
«comprueba»el proceso para que sea posible efectuarrefi- 
namientos.- 

Refinamientoe instanciación. Basándose en la rea- 
limentación procedente del prototipo, se refina el pro- 
ceso de negocio y después se instancia en el seno de un 
sistema de negocio. 


En algunas ocasiones las actividades de RPN descritas 
anteriormente se utilizan junto con herramientas de análi- 
sis del flujo de trabajo. El objetivo de estas herramientas 
es construirun modelo del flujo de trabajo existente, en un 
esfuerzo por analizar mejor los procesos existentes. Ade- 
más, para implementar las cuatro primeras actividades des- 
critas en el modelo de procesos se pueden utilizar las 
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técnicas de modelado que se asocian normalmente a las 
actividades de ingeniería de la información tales como la 
planificación de estrategias de información y el análi- 
sis de áreas de negocios (Capítulo 10). 


30.1.4. Advertencias 


Es muy frecuente que se exagere la importancia de un 
nuevo enfoque de negocio - e n este caso, la RPN-— 
como si fuese la panacea, para después criticarla con 
tanta severidad que pase a ser un desecho. A lo largo de 
los Últimos años, se ha debatido de forma exagerada 
acerca de la eficacia de la RPN (por ejemplo: [BLE93] 
y [DIC95]). En un resumen excelente del caso a favor 
y en contra de la RPN, Weisz (WEI95) expone su argu- 
mento de la manera siguiente: 


Resulta tentador atacar a la RPN como si se tratase de otra 
reencarnación de la famosa bala de plata. Desde varios puntos 
de vista — pensamientode sistemas, tratamiento de personal, 
simple historia — habría que predecir unos índices de fallos 
elevados para el concepto, índices que parecen ser confirma- 


Este escenario resulta sumamente conocido: Una apli- 
cación ha dado servicio y ha cubierto las necesidades 
del negocio de una compañía durante diez o quince años. 
A lo largo de este tiempo, ha sido corregida, adaptada 
y mejorada muchas veces. Las personas se dedicaban a 
esta tarea con la mejor de sus intenciones, pero las prác- 
ticas de ingeniería del software buenas siempre se echa- 
ban a un lado (por la urgencia de otros problemas). 
Ahora la aplicación se ha vuelto inestable. Sigue fun- 
cionando, pero cada vez que intenta efectuar un cam- 
bio se producen efectos colaterales graves e inesperados. 
¿Qué se puede hacer? 

La imposibilidad de mantener el software no es un 
problema nuevo. De hecho, el gran interés por la rein- 
geniería del software ha sido generado por un «iceberg» 
de mantenimiento de software que lleva creciendo des- 
de hace más de treinta años. 


SEL ofrece una variedad de recursos 
de reingeniería del software en la 
dirección: www.sei.cmu.edu/reengineering/ 


30.2.1. Mantenimiento del software 


Hace casi treinta años, el mantenimiento del software 
se caracterizaba [CAN72] por ser como un «iceberg». 
Esperábamos que lo que era inmediatamente visible fue- 
ra de verdad lo que había, pero sabíamos que una enor- 
me masa de posibles problemas y costes yacía por 
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dos por la evidencia empírica. Para muchas compañías parece 
que la bala de plata no da en el blanco. 


Para otras, sin embargo, el nuevo esfuerzo de la reingenie- 
ría ha tenido evidentemente su fruto... 


La RPN puede funcionar, si es aplicada por personas 
motivadas y formadas, que reconozcan que el proceso de 
reingeniería es una actividad continua. Si la RPN se lle- 
va a cabo de forma efectiva, los sistemas de información 
se integran mejor con los procesos de negocios. Dentro 
del contexto de una estrategiamás amplia de negocios se 
puede examinar la reingeniería de aplicacionesmás anti- 
guas, y también se pueden establecer de forma inteligente 
las prioridades de reingeniería del software. 

Aunque la reingeniería de negocio sea una estrate- 
gia rechazada por una compañía, la reingeniería del soft- 
ware es algo que debe hacerse. Existen decenas de 
millares de sistemas heredados — aplicaciones crucia- 
les para el éxito de negocios grandes y pequeños — que 
se ven afectados por una enorme necesidad de ser 
reconstruidos o rehechos en su totalidad. 


rai 


debajo de la superficie. A principios de los años 70, el 
iceberg de mantenimiento era lo suficientemente gran- 
de como para hundir un portaaviones. En la actualidad 
podría hundir toda la Armada. 

El mantenimiento del software existente puede dar 
cuenta de más del 60 por 100 de las inversiones efec- 
tuadas por una organización de desarrollo, y ese por- 
centaje sigue ascendiendo a medida que se produce más 
software [HAN93]. Los lectores que tengan menos 
conocimientos en estos temas podrían preguntarse por 
qué se necesita tanto mantenimiento, y por qué se invier- 
te tanto esfuerzo. Osborne y Chifosky [OSB90] ofre- 
cen una respuesta parcial: 

Gran parte del software del que dependemos en la actua- 
lidad tiene por término medio entre diez y quince años de 
antigiedad. Aun cuando estos programas se crearon emple- 
ando las mejores técnicas de diseño y codificación conoci- 
das en su época (y la mayoría no lo fueron), se crearon 
cuando el tamaño de los programas y el espacio de alma- 
cenamiento eran las preocupaciones principales. A conti- 
nuación, se trasladaron a las nuevas plataformas, se ajustaron 
para adecuarlos a cambios de máquina y de sistemas ope- 
rativos y se mejoraron para satisfacer nuevas necesidades 
del usuario; y todo esto se hizo sin tener en cuenta la arqui- 
tectura global. 


El resultado son unas estructuras muy mal diseñadas, una 
mala codificación, una lógica inadecuada, y una escasadocu- 
mentación de los sistemas de software que ahora nos piden 
que mantengamos en marcha... 


La naturaleza ubicua del cambio subyace en todos 
los tipos de trabajo del software. El cambio es algo ine- 
vitable cuando se construyen sistemas basados en com- 
putadoras; por tanto debemos desarrollar mecanismos 
para evaluar, controlar y realizar modificaciones. 
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montenimiento y de comprensión son 
cuonto más difícil sea de aprender 
dficl será de montener. 


Al leer los párrafos anteriores, un lector podría argu- 
mentar: «...pero yo no invierto el 60 por 100 de mi tiem- 
po corrigiendo errores de los programas que desarrollo». 
Por supuesto, el mantenimiento del software es algo que 
va mucho más allá de «corregir errores». El mantenimiento 
se puede definir describiendo las cuatro actividades 
[SWA76] que se emprenden cuando se publica un progra- 
ma para su utilización. En el Capítulo 2 se definieron cua- 
tro actividades diferentes de mantenimiento: mantenimiento 
correctivo, mantenimiento adaptativo, mejoras o mante- 
nimiento de perfeccionamiento y mantenimiento preventi- 
vo o reingeniería. "Tan sólo el 20 por 100 de nuestros 
esfuerzos de mantenimiento se invertirán «corrigiendo erro- 
res». El 8SOpor 100 se dedicará a adaptar los sistemas exis- 
tentes a los cambios de su entorno externo, a efectuar las 
mejoras solicitadaspor los usuarios y arehacer la ingenie- 
ría de las aplicaciones para su posterior utilización. Cuan- 
do se considera que el mantenimiento abarca todas estas 
actividades, es fácil ver por qué absorbe tanto esfuerzo. 


30.2.2. Un modelo de procesos de reingeniería 
del software 


La reingeniería requiere tiempo; conlleva un coste de 
dinero enorme y absorbe recursos que de otro modo 
podrían emplearse en preocupaciones más inmediatas. 
Por todas estas razones, la reingeniería no se lleva a 
cabo en unos pocos meses, ni siquiera en unos pocos 
años. La reingeniería de sistemas de información es una 
actividad que absorberá recursos de las tecnologías de 
la información durante muchos años. Esta es la razón 
por la cual toda organización necesita una estrategia 
pragmática para la reingeniería del software. 

Una estrategia de trabajo también acompaña al mode- 
lo de procesos de reingeniería. Más adelante, en esta 
misma sección, se describirá este modelo, pero veamos 
en primer lugar algunos de los principios básicos. 

La reingeniería es una tarea de reconstrucción, y se 
podrá comprender mejor la reingeniería de sistemas de 
información si tomamos en consideración una activi- 
dad análoga: la reconstrucción de una casa. Considere- 
mos la situación siguiente: 

Suponga que ha adquirido una casa en otro lugar. 
Nunca ha llegado a ver la finca realmente, pero la con- 
siguió por un precio sorprendentementereducido, advir- 
tiéndosele que quizá fuera preciso reconstruirla en su 
totalidad. ¿Cómo se las arreglaría? 

Antes de empezar a construir, sería razonable inspec- 
cionar la casa. Para determinar si necesita una recons- 
trucción, usted (o un inspector profesional) creará una 
lista de criterios para que la inspección sea sistemática. 
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Antes de derribar y de construir toda la casa, asegú- 
rese de que la estructura está en mal estado. Si la casa 
tiene una buena estructura, quizá sea posible remo- 
delarla sin reconstruirla (con un coste muy inferior 
y en mucho menos tiempo). 

Antes de empezar a reconstruir, asegúrese de que 
entiende la forma en que se construyó el original. 
Eche una ojeada por detrás de las paredes. Com- 
prenda el cableado, la fontanería y los detalles inter- 
nos de la estructura. Aunque vaya a eliminarlostodos, 
la idea que haya adquirido de ellos le servirán de 
mucho cuando empiece a construirla. 

Si empieza a reconstruir, utilice tan solo los materia- 
les más modernos y de mayor duración. Quizá ahora 
le cuesten un poquito más, pero le ayudarán a evitar 
un mantenimientocostoso y lento en fecha posterior. 
Si ha decidido reconstruir, tenga una actitud disci- 
plinada. Utilice prácticas que den como resultado 
una gran calidad —+tanto hoy como en el futuro —. 


Cionsiof) 


las pasas para una casa indicados aquí son obvios. 
Asegúrese de que su consideraciónsobre el software 
anticuada aplica pasos que sean tar obvios. Pienselo, 
Hay mucha dinero en juego. 


Aunque los principios anteriores se centran en la 
reconstrucción de una casa, son aplicables igualmente 
a la reingeniería de sistemas y aplicaciones basados en 
computadoras. 

Para implementar estos principios, se aplica un modelo 
de proceso de reingeniería del software que define las seis 
actividades mostradas en la Figura 30.2. En algunas oca- 
siones, estas actividades se producen de forma secuencial 
y lineal, pero esto no siempre es así. Por ejemplo, puede ser 
que la ingeniería inversa (la comprensión del funcionamiento 
interno de un programa) tenga que producirse antes de que 
pueda comenzar la reestructuración de documentos. 

El paradigma de la reingeniería mostrado en la figu- 
ra es un modelo cíclico. Esto significa que cada una de 
las actividades presentadas como parte del paradigma 
pueden repetirse en otras ocasiones. Para un ciclo en 
particular, el proceso puede terminar después de cual- 
quiera de estas actividades. 


Análisis de inventario. Todas las organizaciones de 
software deberán disponer de un inventario de todas sus 
aplicaciones. El inventario puede que no sea más que una 
hoja de cálculo con la información que proporciona una 
descripción detallada (por ejemplo: tamaño, edad, impor- 
tancia para el negocio) de todas las aplicaciones activas. 


Análisis de inventario 
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Los candidatos a la reingeniería aparecen cuando se 
ordena esta información en función de su importancia 
para el negocio, longevidad, mantenibilidad actual y 
otros criterios localmente importantes. Es entonces cuan- 
do es posible asignar recursos a las aplicaciones candi- 
datas para el trabajo de reingeniería. 


Es importante destacar que el inventario deberá revi- 
sarse con regularidad. El estado de las aplicaciones (por 
ejemplo, la importancia con respecto al negocio) pue- 
de cambiar en función del tiempo y, como resultado, 
cambiarán también las prioridades para la reingeniería. 


Análisis 
de inventario 


Ingeniería 
directa 


Reectructuracion Reestructuracion 


de datos de documentos 
Reestructuración Ingeniería 
de código inversa 


FIGURA 30.2.Un modelo de proceso de reingeniería 
de software. 


Reestructuración de documentos. Una documen- 
tación escasa es la marca de muchos sistemas hereda- 
dos. ¿Qué se puede hacer al respecto? 


Opción n.* 1: La creación de documentación consume 
muchísimo tiempo. El sistema funciona, y ya nos apañaremos 
con lo que tengamos. En algunos casos, éste es el enfoque 
correcto. No es posible volver a crear la documentación para 
cientos de programas de computadoras. Siun programaesrela- 
tivamente estático está llegando al final de vida útil, y no es 
probable que experimente muchos cambios: ¡dejémoslo así! 

Opción n. 2: Es preciso actualizar la documentación, pero 
se dispone de recursos limitados. Se utilizará un enfoque «del 
tipo documentar si se modifica». Quizá no se necesario volver 
a documentar por completo la aplicación. Más bien se docu- 
mentarán por completo aquellas partes del sistema que estén 
experimentando cambios en ese momento. La colección de 
documentos Útil y relevante irá evolucionando con el tiempo. 


Opciónn. 3: El sistemaes fundamental para el negocio, y 
es preciso volver a documentarlo por completo. En este caso, 
un enfoque inteligenteconsiste en reducir la documentaciónal 
mínimo necesario. 


lor) 


Creesólo la documentación que necesite 
para mejorar su comprensión sobre el software 
No para avanzar una página más. 


Todas y cada una de estas opciones son viables. Las 
organizaciones del software deberán seleccionar aque- 
lla que resulte más adecuada para cada caso. 


546 


Ingenieríainversa. El término «ingeniería inversa» tie- 
ne sus orígenes en el mundo del hardware. Una cierta com- 
pañía desensambla un producto de hardware competitivo 
en un esfuerzo por comprender los-«secretos» del diseño 
y fabricación de su competidor. Estos secretos se podrán 
comprender más fácilmente si se obtuvieran las especifi- 
caciones de diseño y fabricación del mismo. Pero estos 
documentos son privados, y no están disponibles para la 
compañía que efectúa la ingeniería inversa. En esencia, 
una ingeniería inversacon éxito precede de una o más espe- 
cificaciones de diseño y fabricación para el producto, 
mediante el examen de ejemplos reales de ese producto. 


La ingeniería inversa del software es algo bastante 
similar. Sin embargo, en la mayoría de los casos, el pro- 
grama del cual hay que hacer una ingeniería inversa no 
es el de un rival, sino, más bien, el propio trabajo de la 
compañía (con frecuenciaefectuado hace muchos años). 
Los «secretos» que hay que comprenderresultan incom- 
prensibles porque nunca se llegó a desarrollar una espe- 
cificación. Consiguientemente, la ingeniería inversa del 
software es el proceso de análisis de un programa con 
el fin de crear una representación de programa con un 
nivel de abstracción más elevado que el código fuente. 
La ingeniería inversa es un proceso de recuperación de 
diseño. Con las herramientas de la ingeniería inversa se 
extraerá del programa existente información del diseño 
arquitectónico y de proceso, e información de los datos. 


Reestructuración del código. El tipo más común de 
reingeniería (en realidad, la aplicación del término rein- 
geniería sería discutible en este caso) es la reestructu- 
ración del código. Algunos sistemas heredados tienen 
una arquitectura de programa relativamente sólida, pero 
los módulos individuales han sido codificados de una 
forma que hace difícil comprenderlos, comprobarlos y 
mantenerlos. En estos casos, se puede reestructurar el 
código ubicado dentro de los módulos sospechosos. 


Para llevar a cabo esta actividad, se analiza el códi- 
go fuente mediante una herramienta de reestructuración, 
se indican las violaciones de las estructuras de progra- 
mación estructurada, y entonces se reestructura el códi- 
go (esto se puede hacer automáticamente). El código 
reestructurado resultante se revisa y se comprueba para 
asegurar que no se hayan introducido anomalías. Se 
actualiza la documentación interna del código. 


Reestructuraciónde datos. Un programa que posea 
una estructura de datos débil será difícil de adaptar y de 
mejorar. De hecho, para muchas aplicaciones, la arqui- 
tectura de datos tiene más que ver con la viabilidad a 
largo plazo del programa que el propio código fuente. 


A diferencia de la reestructuración de código, que se 
produce en un nivel relativamente bajo de abstracción, 
la estructuración de datos es una actividad de reinge- 
niería a gran escala. En la mayoría de los casos, la rees- 
tructuración de datos comienza por una actividad de 
ingeniería inversa. La arquitectura de datos actual se 
analiza minuciosamente y se definen los modelos de 


www.elsolucionario.net 


datos necesarios (Capítulo 12). Se identifican los obje- 
tos de datos y atributos y, a continuación, se revisan las 
estructuras de datos a efectos de calidad. 


Referencia 


Para poder obtener una gran cantidad de recursos 
para la comunidad de reingeniería visite esto dirección: 
www.comp.lancs.ac.uk / projects Renaissance Web/ 


Cuando la estructura de datos es débil (por ejemplo, 
actualmente se implementan archivos planos, cuando 
un enfoque relacional simplificaría muchísimo el pro- 
cesamiento), se aplica una reingeniería a los datos. 


Dado que la arquitectura de datos tiene una gran 
influencia sobre la arquitectura del programa, y también 
sobre los algoritmos que lo pueblan, los cambios en 
datos darán lugar invariablemente a cambios o bien de 
arquitectura O bien de código. 


Ingeniería directa (forward engineering). En un 
mundo ideal, las aplicaciones se reconstruyen utilizan- 
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do un «motor de reingeniería» automatizado. En el 
motor se insertaría el programa viejo, que lo analizaría, 
reestructuraría y después regeneraría la forma de exhi- 
bir los mejores aspectos de la calidad del software. Des- 
pués de un espacio de tiempo corto, es probable que 
llegue a aparecer este «motor», pero los fabricantes de 
CASE han presentado herramientas que proporcionan 
un subconjunto limitado de estas capacidades y que se 
enfrentan con dominios de aplicacionesespecíficos (por 
ejemplo, aplicaciones que han sido implementadas 
empleando un sistema de bases de datos específico). Lo 
que es más importante, estas herramientas de reinge- 
niería cada vez son más sofisticadas. 


La ingeniería directa, que se denomina también reno- 
vación o reclamación [CHI90], no solamente recupera la 
información de diseño de un software ya existente, sino 
que, además, utiliza esta información para alterarorecons- 
truir el sistema existente en un esfuerzo por mejorar su 
calidad global. En la mayoría de los casos, el software 
procedente de una reingeniería vuelve a implementar la 
funcionalidad del sistema existente, y añade además nue- 
vas funciones y/o mejora el rendimiento global. 


La ingeniería inversa invoca una imagen de «ranura 
mágica». Se inserta un listado de código no estructura- 
do,y no documentado por la ranura, y por el otro lado 
sale la documentación completa del programa de com- 
putadora. Lamentablemente, la ranura mágica no exis- 
te. La ingeniería inversa puede extraer información de 
diseño del código fuente, pero el nivel de abstracción, 
la completitud de la documentación, el grado con el cual 
trabajan al mismo tiempo las herramientas y el analis- 
ta humano, y la direccionalidad del proceso son suma- 
mente variables [CASSS]. 

El nivel de abstracción de un proceso de ingeniería 
inversa y las herramientas que se utilizan para realizarlo 
aluden a la sofisticación de la información de diseño que 
se puede extraer del código fuente. El nivel de abstracción 
ideal deberá ser lo más alto posible. Esto es, el proceso de 
ingeniería inversa deberá ser capaz de derivar sus repre- 
sentacionesde diseño de procedimientos (con un bajo nivel 
de abstracción); y la información de las estructuras de datos 
y de programas (un nivel de abstracción ligeramente más 
elevado); modelos de flujo de datos y de control (un nivel 
de abstracción relativamente alto); y modelos de entida- 
des y de relaciones (un elevado nivel de abstracción). A 
medida que crece el nivel de abstracción se proporciona 
al ingenierodel software información que le permitirá com- 
prender más fácilmente estos programas. 


Lo notación indicado aquí se explica con detalle 
en el Copítulo 12, 


547 


La completitud de un proceso de ingeniería inversa 
alude al nivel de detalle que se proporciona en un deter- 
minado nivel de abstracción. En la mayoría de los casos, 
la completitud decrece a medida que aumenta el nivel 
de abstracción. Por ejemplo, dado un listado del códi- 
go fuente, es relativamente sencillo desarrolla una repre- 
sentación de diseño de procedimientos completa. 
También se pueden derivar representaciones sencillas 
del flujo de datos, pero es mucho más difícil desarrollar 
un conjunto completo de diagramas de flujo de datos o 
un diagrama de transición de estados. 


A 

VE 
Se deben ofrontar tres enfoques de ingeniería inversa: 
nivel de obstracción, completitud y direccionolidad. 


La completitud mejora en proporción directaa la can- 
tidad de análisis efectuado por la persona que está efec- 
tuando la ingeniería inversa. La interactividud alude al 
grado con el cual el ser humano se «integra» con las 
herramientas automatizadas para crear un proceso de 
ingeniería inversa efectivo. En la mayoría de los casos, 
a medida que crece el nivel de abstracción, la interacti- 
vidad deberá incrementarse, O sino la completitud se 
verá reducida. 

Si la direccionalidad del proceso de ingeniería inver- 
saes monodireccional, toda la información extraída del 
código fuente se proporcionará a la ingeniería del soft- 
ware que podrá entonces utilizarla durante la actividad 
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de mantenimiento. Si la direccionabilidad es bidirec- 
cional, entonces la información se suministrará a una 
herramienta de reingeniería que intentará reestructurar 
o regenerar el viejo programa. 


Código fuente sucio 


Reestructuración 
del código 


Procesamiento 


Código fuente limpio 
l 


Extraer 
abstracciones 


Base 
de datos 


Sy 


Especificación inicial 
Ll 


Refinar 


y simplificar 


Especificación final 


y 


FIGURA 30.3.El proceso de ingeniería inversa. 


El proceso de la ingeniena se representa en la Figu- 
ra 30.3. Antes de que puedan comenzar las actividades 
de ingeniería inversa, el código fuente no estructurado 
(«sucio»)se reestructura (Sección 30.4.1)para que sola- 
mente contengaconstrucciones de programación estmuc- 
turada?. Esto hace que el código fuente sea más fácil de 
leer, y es lo que proporciona la base para todas las acti- 
vidades subsiguientes de ingeniería inversa. 


Referencia Web 


La página de Recuperaciónde diseños y entendimiento 
de programas proporcionalos recursos útiles para un trabajo 
de reingeniería: www.sel.iit.nrc.ca/projects / dr / dr. html 


El núcleo de la ingeniería inversa es una actividad 
denominada extracción de abstracciones. El ingeniero 
tiene que evaluar el viejo programa y a partir del códi- 
go fuente (que no suele estar documentado) tiene que 
extraer una especificación significativa del procesa- 


* El código se puede reestructurar automáticamente empleando un 
((motorde reestructuración), —una herramienta CASE que reestruc- 
tura el código fuente—. 


l.-- J 
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miento que se realiza, la interfaz de usuario que se apli- 
ca, y las estructuras de datos de programa o de base de 
datos que se utiliza. 


30.3.1. Ingeniería inversa para comprender 
el procesamiento 


La primera actividad real de la ingeniería inversa 
comienza con un intento de comprender y extraer des- 
pués abstracciones de procedimientos representadas por 
el código fuente. Para comprender las abstraccionesde 
procedimientos, se analiza el código en distintos nive- 
les de abstracción: sistema, programa, componente, con- 
figuración y sentencia. 

La funcionalidad general de todo el sistema de apli- 
caciones deberá ser algo perfectamente comprendido 
antes de que tenga lugar un trabajo de ingeniería inversa 
más detallado. Esto es lo que establece un contexto para 
un análisis posterior, y se proporcionan ideas generales 
acerca de los problemas de interoperabilidadentre apli- 
caciones dentro del sistema. Cada uno de los programas 
de que consta el sistema de aplicacionesrepresentaráuna 
abstracción funcional con un elevado nivel de detalle. 
También se creará un diagrama de bloques comorepre- 
sentación de la iteración entre estas abstracciones fun- 
cionales. Cada uno de los componentes efectúa una 
subfunción, y representa una abstracción definida de pro- 
cedimientos. En cada componente se crea una narrativa 
de procesamiento. En algunas situaciones ya existen espe- 
cificaciones de sistema, programa y componente. Cuan- 
do ocurre tal cosa, se revisan las especificaciones para 
preciar si se ajustan al código existente”. 


gran pasión por la comprensión, 

y posión que existe por la músico. 
n es bastante común en los niños, 
lo mayoría de los personas más 

is temprano desaparece. 


Todo se complica cuando se considera el código que 
reside en el interior del componente. El ingeniero bus- 
ca las secciones de código que representan las configu- 
raciones genéricas de procedimientos. En casi todos los 
componentes, existe una sección de código que prepa- 
ra los datos para su procesamiento (dentro del compo- 
nente), una sección diferente de código que efectúa el 
procesamiento y otra sección de código que prepara los 
resultados del procesamiento para exportarlos de ese 
componente. En el interior de cada una de estas sec- 
ciones, se encuentran configuraciones más pequeñas. 


Con frecuencia, las especificaciones escritas en fases centradas de 
la historia del programa no llegan a actualizarse nunca. A medida 
que se hacen cambios, el código deja de satisfacer esas especifica- 
ciones. 
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Por ejemplo, suele producirse una verificación de los 
datos y una comprobación de los límites dentro de la 
sección de código que prepara los datos para su proce- 
samiento. 

Para los sistemas grandes, la ingeniería inversa sue- 
le efectuarse mediante el uso de un enfoque semiauto- 
matizado. Las herramientas CASE se utilizan para 
«analizar» la semántica del código existente. La salida 
de este proceso se pasa entonces a unas herramientas 
de reestructuración y de ingeniería directa que comple- 
tarán el proceso de reingeniería. 


30.3.2. Ingeniería inversa para comprender 
los datos 


La ingeniería inversa de datos suele producirse a dife- 
rentes niveles de abstracción. En el nivel de programa, 
es frecuente que sea preciso realizar una ingeniería inver- 
sa de las estructuras de datos internas del programa, 
como parte del esfuerzo general de la reingeniería. En 
el nivel del sistema, es frecuente que se efectúe una rein- 
geniería de las estructuras globales de datos (por ejem- 
plo: archivos, bases de datos) para ajustarlas a los 
paradigmas nuevos de gestión de bases de datos (por 
ejemplo, la transferencia de archivos planos a unos sis- 
temas de bases de datos relacionales u orientados a obje- 
tos). La ingeniería inversa de las estructuras de datos 
globales actuales establecen el escenario para la intro- 
ducción de una nueva base de datos que abarque todo 
el sistema. 


Estructuras de datos internas. Las técnicas de inge- 
niería inversa para datos de programa internos se cen- 
tran en la definición de clases de objetos”. Esto se logra 
examinando el código del programa en un intento de 
agrupar variables de programa que estén relacionadas. 
En muchos casos, la organización de datos en el seno 
del código identifica los tipos abstractos de datos. Por 
ejemplo, las estructuras de registros, los archivos, las 
listas y otras estructuras de datos que suelen propor- 
cionar una indicación inicial de las clases. 


Para la ingeniería inversa de clases, Breuer y Lano 
[BRE91] sugieren el enfoque siguiente: 


1 Identificación de los indicadores y estructuras de 
datos locales dentro del programa que registran infor- 
mación importante acerca de las estructuras de datos 
globales (por ejemplo, archivos o bases de datos). 


2 Definición de la relación entre indicadores y estruc- 
turas de datos locales y las estructuras de datos glo- 
bales. Por ejemplo, se podrá activar un indicador 
cuando un archivo esté vacío; una estructura de 
datos local podrá servir como memoria intermedia 
de los cien últimos registros recogidos para una 
base de datos central. 


$ Para una descripción completa de estos conceptos orientados a 
objetos, véase la Parte Cuarta de este libro. 
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3. Para toda variable (dentro de un programa) que repre- 
sente una matriz o archivo, la construcción de un lis- 
tado de todas las variables que tengan una relación 
lógica con ella. 


Corso) 


En los próximos años los compromisosrelativamente 
significotivos en /asestructuras de datos pueden conducir 
9 tener problemos potencialmentecatostróficos. Fíjese 
por ejemplo en el efecto delaño 2000. 


Estos pasos hacen posible que el ingeniero del soft- 
ware identifique las clases del programa que interactú- 
an con las estructuras de datos globales. 


Estructuras de bases de datos. Independientemen- 
te de su organización lógica y de Su estructura física, 
las bases de datos permiten definir objetos de datos, y 
apoyan los métodos de establecerrelaciones entre obje- 
tos. Por tanto, la reingeniería de un esquema de bases 
de datos para formar otro exige comprenderlos objetos 


ya existentes y sus relaciones. 
¿Cuáles son los pasos que 


2 se pueden aplicar para aplicar 
la ingeniería inversa en una estructura 
de bases de datos existente? 


Para definir el modelo de datos existente como pre- 
cursor para una reingeniería que producirá un nuevo 
modelo de base de datos se pueden emplear los pasos 
siguientes [PRE94] : 

1. Construcción de un modelo de objetos inicial. Las 
claves definidas como parte del modelo se podrán 
conseguir mediante la revisión de registros de una 
base de datos de archivos planos o de tablas de un 
esquema relacional. Los elementos de esos registros 

O tablas pasarán a ser atributos de una clase. 

. Determinaciónde los candidatos a claves. Los atribu- 
tos se examinan para determinar si se van a utilizar O 
no para señalar a otro registro o tabla. Aquellos que sir- 
van como punteros pasarán a ser candidatos a claves. 


. Refinamiento de las clases provisionales. Se deter- 
mina si ciertas clases similares pueden o no combi- 
narse dentro de una Unica clase. 


. Definición de las generalizaciones. Para determinar 
si se debe o no construir una jerarquía de clases con 
una clase de generalización como precursor de todos 
sus descendentes se examinan las clases que pueden 
tener muchos atributos similares. 


. Descubrimiento de las asociaciones. Mediante el uso 
de técnicas análogas al enfoque de CRC (Capí- 
tulo 21) se establecen las asociaciones entre clases. 
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Una vez que se conoce la información definida en los 
pasos anteriores, se pueden aplicar una serie de trans- 
formaciones [PRE94] para hacer corresponder la estruc- 
tura de la vieja base de datos con una nueva estructura 
de base de datos. 


30.3.3. Ingeniería inversa de interfaces 
de usuario 


Las IGUs sofisticadas se van volviendo de rigor para 
los productos basados en computadoras y para los sis- 
temas de todo tipo. Por tanto el nuevo desarrollo de 
interfaces de usuario ha pasado a ser uno de los tipos 
más comunes de las actividades de reingeniería. Aho- 
ra bien, antes de que se pueda reconstruir una interfaz 
de usuario, deberá tener lugar una actividad de inge- 


niería inuersa. 
0 ¿Cómo puedo entender 
el funcionamiento de la 
interfaz de usuario existente? 


Para comprender totalmente una interfaz de usuario 
ya existente (IU), es preciso especificar la estructura y 
comportamiento de la interfaz. Merlo y sus colabora- 
dores [MER93] sugieren tres preguntas básicas a las 
cuales hay que responder cuando comienza la ingenie- 
ría inversa de la IU: 


¿Cuáles son las acciones básicas que deberá proce- 


sar la interfaz, por ejemplo, acciones de teclado y 
clics de ratón? 


¿Cuál es la descripción compacta de la respuesta de 
comportamiento del sistema a estas acciones? 


¿Qué queremos decir con «sustitución», o más exac- 
tamente, qué concepto de equivalencia de interfaces 
es relevante en este caso? 


La notación de modelado de comportamiento (Capí- 
tulo 12)puede proporcionaruna forma de desarrollar las 
respuestas de las dos primeras preguntas indicadas ante- 
riormente. Gran parte de la información necesaria para 
crear un modelo de comportamiento se puede obtener 
mediante la observación de la manifestación externa de 
la interfaz existente. Ahora bien, es preciso extraer del 
código la información adicional necesaria para crearel 
modelo de comportamiento. 

Es importante indicar que una IGU de sustitución 
puede que no refleje la interfaz antigua de forma exac- 
ta (de hecho, puede ser totalmente diferente). Con fre- 
cuencia, merece la pena desarrollar metáforas de 
interacción nuevas. Por ejemplo, una solicitud de TU 
antigua en la que un usuario proporcione un 
superior (del la 10)para encoger o agrandar una ima- 
gen gráfica. Es posible que una IGU diseñada utilice 
una barra de imágenes y un ratón para realizar la mis: 
ma función. 


La reestructuración del software modifica el código 
fuente y/o los datos en un intento de adecuarlo a futu- 
ros cambios. En general, la reestructuración no modifi- 
ca la arquitectura global del programa. Tiende a centrarse 
en los detalles de diseño de módulos individuales y en 
estructuras de datos locales definidas dentro de los 
módulos. Si el esfuerzo de la reestructuración se extien- 
de más allá de los límites de los módulos y abarca la 
arquitectura del software, la reestructuración pasa a ser 
ingeniería directa (Sección 30.5). 


Amold [ARN89] define un cierto número de bene- 
ficios que se pueden lograr cuando se reestructura el 
software: 
+. Programas de mayor calidad —con mejor docu- 

mentación y menos complejidad, y ajustados a las 

prácticas y estándares de la ingeniería del software 
moderna —. 


¿Qué beneficios se derivan 
de la reestructuración? 
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Reduce la frustración entre ingenieros del software 
que deban trabajar con el programa, mejorando por 
tanto la productividad y haciendo más sencillo el 
aprendizaje. 

Reduce el esfuerzo requerido para llevar a cabo las 
actividades de mantenimiento. 

Hace que el software sea más sencillo de comprobar 
y de depurar. 


La reestructuración se produce cuando la arquitectura 
básica de la aplicaciónes sólida, aun cuando sus interio- 
ridades técnicas necesiten un retoque. Comienza cuando 
existen partes considerables del software que son Útiles 
todavía, y solamente existe un subconjunto de todos los 
módulos y datos que requieren una extensamodificación', 


30.4.1. Reestructuración del código 


La reestructuración del código se lleva a cabo para con- 
seguirun diseño que produzca la misma función pero con 
mayor calidad que el programa original. En general, las 
técnicas de reestructuracióndel código (por ejemplo, las 
técnicas de simplificación lógica de Warnier [WAR74]) 


$ En algunas ocasiones, resulta dificil distinguirentre una reestructura- 
ción extensa y un nuevo desarrollo. Ambos son casos de reingeniería. 
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modelan la lógica del programa empleando álgebra Boo- 
leana, y a continuación aplican una serie de reglas de 
transformación que dan lugar a una lógica reestructura- 
da. El objetivo es tomar el código de forma de «plato de 
espaguetis» y derivar un diseño de procedimientos que 
se ajuste a la filosofía de la programación estructurada 
(Capítulo 16). 


eS 


Aun cuando la reestructuración puede aliviar 

bos problemas inmediatas asociadas a la depuración 
y los pequeños cambios, eso no esreingenierío. 

El beneficia real se fogra salo cuando se 
reestructuran los datas y la arquitectura. 


Se han propuesto también otras técnicas de reestructu- 
ración que puedan utilizarse con herramientas de reinge- 
niería. Por ejemplo, Chot y Acacchi [CHO90] sugieren la 
creación de un diagrama de intercambio de recursos que 
diseña cada uno de los módulos de programa y los recur- 
sos (tipos de datos, procedimientos y variables) que se 
intercambian en este y otros módulos. Mediante la crea- 
ción de representaciones del flujo de recursos, la arqui- 
tectura del programa se puede reestructurar para lograr 
el acoplamiento mínimo entre los módulos. 


30.4.2. Reestructuración de los datos 


Antes de que pueda comenzar la reestructuración de 
datos, es preciso llevar a cabo una ingeniería inver- 
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sa, llamada análisis del código fuente. En primer 
lugar se evaluarán todas las sentencias del lenguaje 
de programación con definiciones de datos, des- 
cripciones de archivos, de E/S, y descripciones de 
interfaz. El objetivo es extraer elementos y objetos 
de datos, para obtener información acerca del flujo 
de datos, así como comprender las estructuras de 
datos ya existentes que se hayan implementado. Esta 
actividad a veces se denomina análisis de datos 
[RIC89]. 

Una vez finalizado el análisis de datos, comien- 
za el rediseño de datos. En su forma más sencilla se 
emplea un paso de estandarización de rediseño de 
datos que clarifica las definiciones de datos para 
lograr una consistencia entre nombres de objetos de 
datos, o entre formatos de registros físicos en el seno 
de la estructura de datos o formato de archivos exis- 
tentes. Otra forma de rediseño, denominada racio- 
nalización de nombres de datos, garantiza que todas 
las convenciones de denominación de datos se ajus- 
ten a los estándares locales, y que se eliminen las 
irregularidades a medida que los datos fluyen por el 
sistema. 

Cuando la reestructuración sobrepasa la estandari- 
zación y la racionalización, se efectúan modificaciones 
físicas en las estructuras de datos ya existentes con obje- 
to de hacer que el diseño de datos sea más efectivo. Esto 
puede significaruna conversión de un formato de archi- 
vo a otro, o, en algunos casos, una conversión de un tipo 
de base de datos a otra. 


Un programa que posea flujo de control es el equivalente 
gráfico de un plato de espaguetis con «módulos»,es decir 
con 2.000 sentencias de longitud; con pocas líneas de 
comentario útiles en 290.000 sentenciasde código fuente, 
y sin ninguna otra documentación que se deba modificar 
para ajustarle a los requisitos de cambios del usuario. Se 
puede decir que disponemos de las opciones siguientes: 


1. La posibilidad de esforzarse por efectuar una modi- 
ficación tras otra, luchando con el diseño implícito 
y con el código fuente para implementar los cambios 
necesarios. 

2. La posibilidad de intentar comprender el funciona- 
miento interno más amplio del programa, en un esfuerzo 
por hacer que las modificaciones sean más efectivas. 


a ¿Qué opciones existen 
cuando nos enfrentamos 
con un programa de diseño 
e implementeciónpobres? 


3. La posibilidad de rediseñar, recodificar y comprobar 
aquellas partes del software que requieran modifi- 


caciones, aplicando un enfoque de ingeniería del soft- 
ware a todos los segmentos revisados. 


4. La posibilidad de rediseñar, recodificar y comprobar 
el programa en su totalidad, utilizando herramientas 
CASE (herramientas de reingeniería) que servirán 
para comprender el diseño actual. 


No existe una Única opción «correcta».Las circuns- 
tancias pueden imponer la primera opción, aun cuando 
las otras sean las preferidas. 

En lugar de esperar a que se reciba una solicitud 
de mantenimiento, la organización de desarrollo o 
de soporte utilizará los resultados del análisis de 
inventario para seleccionar el programa (1) que con- 
tinúe utilizándose durante un número determinado 
de años, (2) que se esté utilizando con éxito en la 
actualidad, y (3) que tenga probabilidades de sufrir 
grandes modificaciones o mejoras en un futuro pró- 
ximo. Entonces, se aplicarán las opciones 2,364 
anteriores. 

Este enfoque de mantenimiento preventivo fue intro- 
ducido por Miller [MIL81] con el nombre de «reajuste 
estructurado». Definía este concepto como «la aplica- 
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ción de las metodologías de hoy a los sistemas de ayer 
para prestar apoyo a los requisitos del mañana». 

A primera vista, la sugerencia de volver a desarro- 
llar un gran programa cuando ya existe una versión ope- 
rativa puede parecer más bien extravagante. Sin 
embargo, antes de pasar a emitir un juicio, considéren- 
se los puntos siguientes: 


1. El coste de mantener una línea de código fuente 
puede estar entre veinte y cuarenta veces por encima 


del coste del desarrollo inicial de esa línea. 


. El rediseño de la arquitectura del software (del pro- 
grama y/o de las estructuras de datos) empleando 
conceptos de diseño modernos puede facilitar mucho 
el mantenimiento futuro. 


Dado que ya existe un prototipo del software, la pro- 
ductividad de desarrollo deberá ser mucho más ele- 
vada que la media. 


. En la actualidad, el usuario ya tiene experiencia con 
el software. Por tanto, los nuevos requisitos y la direc- 
ción del cambio se podrán estimarse con mucha más 
facilidad. 


. Las herramientas CASE para la reingeniería auto- 
matizarán algunas partes del trabajo. 


. Cuando finalice el mantenimientopreventivo, se dis- 
pondrá de una configuración completa del software 
(documentos, programas y datos). 


Conse) 


la reingenieríaes muy similar al hecho de lavarse 
los dientes. Se puede pensar en mil razanes 

y tardar en lavárselas, dejándoloparo más tarde, 
Pera, al final, estas tácticas de retrasar los Cosos 
siempre volverán a rondarnos. 


Cuando una organización de desarrollo de software 
vende el software como un producto, el mantenimien- 
to preventivo se ve como «nuevas versiones» del pro- 
grama. Un gran desarrollador de software local (por 
ejemplo, un grupo de desarrollo de software de siste- 
mas para una compañía de productos de un consumidor 
de gran volumen) puede tener entre 500 y 2.000 pro- 
gramas de producción dentro de su dominio de respon- 
sabilidad. Se podrán asignar prioridades a estos 
programas según su importancia, y a continuación se 
revisarán esos programas como los candidatos para el 
mantenimiento preventivo. 

El proceso de ingeniería del software aplica prin- 
cipios, conceptos y métodos de ingeniería del softwa- 
re para volver a crear las aplicaciones existentes. En 
la mayoría de los casos, la ingeniería directa no se limi- 
ta a crear un equivalente moderno de un programa ante- 
rior, sino que más bien se integran los nuevos requisitos 
y las nuevas tecnologías 'en ese esfuerzo de volver a 
aplicar reingeniería. El programa que se ha vuelto a 
desarrollar amplía las capacidades de la aplicación 
anterior. 
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30.5.1. Ingeniería directa para arquitecturas 
cliente/servidor 


A lo largo de la última década, muchas aplicaciones de 
grandes computadoras han sufrido un proceso de rein- 
geniería para adaptarlas a arquitecturas cliente/servidor 
(C/5). En esencia, los recursos de computación centra- 
lizados (incluyendo el software) se distribuyen entre 
muchas plataformas cliente. Aunque se puede diseñar 
toda una gama de entornos distribuidos distintos, la apli- 
cación típica de computadora central que sufre un pro- 
ceso de reingeniería para adoptar una arquitectura 
cliente/servidor posee las características siguientes: 


la funcionalidad de la aplicación migra hacia todas 
las computadoras cliente; 


se implementan nuevas interfaces IGU en los cen- 
tros clientes; 


las funciones de bases de datos se le asignan al ser- 
vidor; 

la funcionalidad especializada (por ejemplo, los aná- 
lisis de computación intensiva) pueden permanecer 
en el centro del servidor; y 


los nuevos requisitos de comunicaciones, seguridad, 
archivado y control deberán establecerse tanto en el 
centro cliente, como en el centro servidor. 


Referencia cruzada 


La ingeniería del software cliente /servidor 
se estudia en el Copítulo:28. 


Es importante tener en cuenta que la migración des- 
de computadoras centrales a un proceso C/S requiere 
tanto una reingeniería del negocio como una reínge- 
niería del software. Además, es preciso establecer una 
«infraestructura de red de empresa». [JAY94] 


o 


Enalgunos casas, los sistemas (/S o los sistemas 00 
diseñadospara reemplazar una aplicación antigua deberán 
enfocarse como un proyecto nuevo de desarrollo. 

La reingenieríaentra en juega solo cuando los elementos 
de un sistemaantiguo se von a integrar con la nueva 
arquitectura. En algunos casos, quizás es mejor no aceptar 
la viejay crear unafuncionalidad nueva e idéntico. 


La reingeniería de aplicaciones C/S comienza con 
un análisis exhaustivo del entorno de negocios que abar- 
ca la computadora central existente. Se pueden identi- 
ficar tres capas de abstracción (Fig. 30.4).La base de 
datos se encuentra en los cimientos de la arquitectura 
cliente/servidor, y gestiona las transacciones y consul- 
tas que proceden de las aplicaciones de servidor. Sin 
embargo, estas transacciones y consultas tienen que ser 
controladas en el contexto de un conjunto de reglas de 
negocio (definidas por un proceso de negocio ya exis- 
tente o que ha experimentado una reingeniería). Las 
aplicaciones de cliente proporcionan la funcionalidad 
deseada para la comunidad de usuarios. 
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Las funciones del sistema de gestión de bases de 
datos ya existente y la arquitectura de datos de la base 
de datos existente deberán sufrir un proceso de inge- 
niería inversa como precedente para el rediseño de la 
capa de fundamento de la base de datos. En algunos 
casos, se crea un nuevo modelo de datos (Capítulo 12). 
En todos los casos, la base de datos C/S sufre un pro- 
ceso de reingeniería para asegurar que las transaccio- 
nes se ejecutan consistentemente; para asegurar que 
todas las actualizaciones se efectúen únicamente por 
usuarios autorizados; para asegurar que se impongan 
las reglas de negocios fundamentales (por ejemplo, antes 
de borrar el registro de un proveedor, el servidor se ase- 
gura de que no exista ningún registro pendiente, con- 
trato o comunicación para ese proveedor); para asegurar 
que se puedan admitir las consultas de forma eficaz; y 
para asegurar que se ha establecido una capacidad com- 
pleta de archivado. 


Interfaz: IGU 


Aplicaciones cliente 


Interfaz: solicitudes de proceso 


Interfaz: transacciones y consultas 


Base de datos 


FIGURA 30.4. Proceso de reingeniería de aplicaciones 
de computadores centrales a cliente/servidor. 


La capa de reglas de negocios representa el software 
residente tanto en el cliente como en el servidor. Este 
software lleva a cabo las tareas de control y coordina- 
ción para asegurar que las transacciones y consultas 
entre la aplicación cliente y la base de datos se ajusten 
a los procesos de negocios establecidos. 

La capa de aplicación del cliente implementa las fun- 
ciones de negocios requeridas por grupos específicos de 
usuarios finales. En muchos casos, se segmenta una apli- 
cación de computadora central en un cierto número de 
aplicaciones más pequeñas, sometidas a reingeniería, y 
adecuadas para su funcionamiento de sobremesa. La 
comunicaciónentre aplicaciones de sobremesa (cuando 
es necesaria) será controlada por la capa de reglas de 
negocios. 


CAPÍTULO 30 REINGENIERÍA 


Un estudio completo sobre el diseño y reingeniería 
de software cliente/servidor es más adecuado para otros 
libros especializados en este materia. El lector intere- 
sado deberá consultar [VAS93], [INM93| y [BER92]. 


30.5.2. Ingeniería directa para arquitecturas 
orientadas a objetos 


La ingeniería del software orientada a objetos se ha trans- 
formado en el paradigma opcional de desarrollo para 
muchas organizaciones de software. Sin embargo, ¿qué 
sucede con las aplicaciones existentes que se desarro- 


.llaron empleando métodos convencionales? En algunos 
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casos, la respuesta consiste en dejar estas aplicaciones 
tal y como eran. Pero en otros casos, es preciso aplicar 
una reingeniería a las viejas aplicaciones para que se 
puedan integrar fácilmente en grandes sistemas orienta- 
dos a objetos. 

La reingeniería del software convencional para pro- 
ducir una implementación orientada a objetos hace uso 
de muchas de las mismas técnicas descritas en la Cuar- 
ta Parte de este libro. En primer lugar, se hace una inge- 
niería inversa del software existente para que sea posible 
crear los modelos adecuados de datos, funcional y de 
comportamiento. Si el sistema que se aplica a la reinge- 
niería extiende la funcionalidad o comportamientode la 
aplicación original, se crean casos prácticos (Capítulos 
11 y 21). Los modelos de datos creados durante la inge- 
niería inversa se utilizan entonces junto con un modela- 
do CRC (Capítulo 21) para establecer la base para la 
definición de clases. Las jerarquías de clases, los mode- 
los de relaciones entre objetos, los modelos de compor- 
tamiento de objetos, y los subsistemas se definen a 
continuación, y comienza el diseño orientado a objetos. 

A medida que la ingenieríadirecta orientada a objetos 
pasa del análisis hasta el diseño, se podrá invocar el mode- 
lo de proceso de ISBC (Capítulo 27). Si la aplicación exis- 
tente se encuentracon un dominio ya ha sido popularizada 
por muchas aplicaciones orientadas a objetos, es proba- 
ble que exista una biblioteca robusta de componentes y 
que se pueda utilizar durante la ingeniería directa. 

Para aquellas clases que sea preciso construirpartiendo 
de cero, quizá sea posible reutilizar algoritmos y estruc- 
turas de datos procedentes de la aplicación convencional 
ya existente. Si embargo, es preciso volver a diseñarlos 
para ajustarse a la arquitectura orientada a objetos. 


30.5.3. Ingeniería directa para interfaces 
de usuario 


Cuando las aplicacionesmigran desde la computadora cen- 
tral a la computadora de sobremesa, los usuarios ya no 
están dispuestos a admitir unas interfaces de usuarios arca- 
nas basadas en caracteres. De hecho, una parte significa- 
tiva de todos los esfuerzos invertidos en la transición desde 
la computación de computadora central hasta la arquitec- 
tura cliente/servidor se pueden reinvertir en la reingenie- 
ría de las interfaces de usuario de la aplicación cliente. 
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INGENIERÍA DEL SOFTWARE. UN ruruyur rratiitu 
3 ¿Cuáles son los pasos a seguir 
para una ingeniería de interfaz 
de usuario? 


Merlo y colaboradores[MER95] sugieren el modelo 
siguiente para la reingeniería de interfaces de usuario: 


1. Comprender la interfaz original y los datos que se 
trasladan entre ella y el resto de la aplicación. El 
objetivo es comprender la forma en que los demás 
elementos del programa interactúan con el código 
existente que implementa la interfaz. Si se ha de desa- 
rrollar una nueva IGU, entonces el flujo de datos 
entre la IGU y el resto del programa deberá ser con- 
secuente con los datos que en la actualidad fluyen 
entre la interfaz basada en caracteres y el programa. 


2. Remodelar el comportamiento implícito en interfaz 
existenteparaformar una serie de abstracciones que 
tengan sentido en el contexto de una IGU. Aunque el 
modelo de interacciónpueda ser radicalmente distinto, 
el comportamientode negocios mostrado por los usua- 
rios de la interfaz nueva y vieja (cuando se consideran 
en función del escenario de utilización) deberán seguir 


$ 


siendo los mismos. La interfazrediseñada deberá seguir 
permitiendo que el usuario muestre el comportamiento 
de negocios adecuado. Por ejemplo, cuando se efec- 
túa una consultaen una base de datos, es posible que, 
para especificar la consulta, la interfaz vieja necesite 
una serie larga de Órdenes basadas en textos. La IGU 
sometida a reingeniería puede hacer que la consulta 
sea más eficiente, reduciéndola a una pequeña secuen- 
cia de selecciones con el ratón, pero la intención y el 
contenidode la consultadeberán permanecer intactas. 


Introducir mejoras que hagan que el modo de inter- 
acción sea más eficiente. Los fallos ergonómicos de 
la interfaz existente se estudian y se corrigen en el 
diseño de la IGU nueva. 


Construir e integrar la IGU nueva. La existencia de 
bibliotecas de clases y de herramientas de cuarta 
generación puede reducir el esfuerzo requerido para 
construirla IGU de forma significativa.Sin embargo, 
la integración con el software de aplicación ya exis- 
tente puede llevar más tiempo. Para asegurarse de 
que la IGU no propague unos efectos adversos al 
resto de la aplicación es preciso tener cuidado. 


En un mundo perfecto, todo programa que no se pudie- 
ra mantener se retiraría inmediatamente, para ser susti- 
tuido por unas aplicaciones de alta calidad, fabricadas 
mediante reingeniería y desarrolladas empleando las 
prácticas de la ingeniería del software modernas. Sin 
embargo, vivimos en un mundo de recursos limitados. 
La reingeniería consume recursos que se pueden utili- 
zar para otros propósitos de negocio. Consiguiente- 
mente, antes de que una organización intente efectuar 
una reingeniería de la aplicación existente, deberá lle- 
var a cabo un análisis de costes y beneficios. 
Sneed[SNE95] ha propuesto un modelo de análisis 
de costes y beneficios para la reingeniería. Se definen 
nueve parámetros: 
P¡ =coste de mantenimiento anual actual para una 
aplicación; 
P, =coste de operación anual de una aplicación; 
P, = valor de negocios anual actual de una aplicación; 
P, =coste de mantenimientoanual predicho después 
de la reingeniería; 
Ps =coste de operaciones anual predicho después de 
la reingeniería; 
P¿ = valor de negocio actual predicho después de la 
reingeniería; 
P, =costes de reingeniería estimados; 
Pg = fecha estimada de reingeniería; 
P, =factor de riesgo de la reingeniería (Py = 1,0 es 
el valor nominal); 
L = vida esperada del sistema. 
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El coste asociado al mantenimiento continuado de 
una aplicación candidata (estoes, si no se realiza la rein- 
geniería) se puede definir como: 


Evo = [Py -(P «PIE (30.1) 


Los costes asociados con la reingeniería se definen 
empleando la relación siguiente: 


Creing =UPg- (Py +PHX(L-Pg) (PXPY (302) 


Empleando los costes presentados en la ecuaciones 
(30.1) y (30.2), los beneficios globales de la reingenie- 
ría se pueden calcular en la forma siguiente: 


reing — Cmant (30.3) 


El análisis de costes y beneficios presentados en 
las ecuaciones anteriores se puede llevar a cabo para 
todas aquellas aplicaciones de alta prioridad que se 
hayan identificado durante un análisis de inventario 
(Sección 30.2.2). Aquellas aplicaciones que muestren 
el mayor beneficio en relación con los costes podrán 
destinarse a la reingeniería, mientras que las demás 
podrán ser propuestas hasta que se disponga de más 
recursos. 


Beneficio y coste =C 
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La ingeniería se produce en dos niveles distintos de 
abstracción. En el nivel de negocios, la reingeniería 
se concentra en el proceso de negocios con la inten- 
ción de efectuar cambios que mejoren la competitivi- 
dad en algún aspecto de los negocios. En el nivel del 
software, la reingeniería examina los sistemas y apli- 
caciones de información con la intención de rees- 


tructurarlos o reconstruirlos de tal modo que muestren 
una mayor calidad. 

La reingeniería de procesos de negocio (RPN) defi- 
ne los objetivos de negocios, identifica y evalúa los 
procesos de negocios ya existentes (en el contexto de 
los objetivos definidos), especifica y diseña los pro- 
cesos revisados, y construye prototipos, refina e ins- 
tancia esos procesos en el seno de un negocio. La RPN 
tiene un objetivo que va más allá del software. Su resul- 
tado suele ser la definición de formas en que las tec- 
nologías de la información puedan prestar un mejor 
apoyo a los negocios. 

La reingeniería del software abarca una serie de acti- 
vidades entre las que se incluye el análisis de inventa- 
rio, la reestructuración de documentos, la ingeniería 
inversa, la reestructuración de programas y datos, y la 
ingeniería directa. El objetivo de esas actividades con- 
siste en crear versiones de los programas existentes que 
muestren una mayor calidad, y una mejor mantenibili- 


dad —se trata de programas que sean viables hasta bien 
entrado el siglo veintiuno —. 

El análisis de inventarios permite que una organiza- 
ción estime todas y cada una de las aplicaciones siste- 
máticamente, con el fin de determinar cuáles son las 
candidatas para una reingeniería. La reestructuración 
de documentos crea un marco de trabajo de documen- 
tos necesario para el apoyo de una cierta aplicación a 
largo plazo. La ingeniería inversa es el proceso de ana- 
lizar un programa en un esfuerzo por extraer informa- 
ción acerca de los datos, de su arquitectura y del diseño 
de procedimientos. Por Último, la ingeniería directa 
reconstruye el programa empleando prácticas de inge- 
niería moderna del software y la información obtenida 
durante la ingeniería inversa. 

Los costes y beneficios de la reingeniería se pue- 
den determinar de forma cuantitativa. El coste del sta- 
tus quo, esto es, los costes asociados al mantenimiento 
y soporte que conlleva una aplicación existente se pue- 
de comparar con los costes estimados de la reingenie- 
ría, y con la reducción resultante de los costes de 
mantenimiento. En casi todos los casos en que un pro- 
grama tiene una vida larga y muestra en la actualidad 
un mantenimiento dificultoso, la reingeniería repre- 
senta una estrategia de negocios eficiente en relación 
con los costes. 
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30.1. Considere cualquier trabajo que haya desempeñado en 
los últimos cinco años. Describa el proceso de negocios en 
que haya desempeñado su función. Utilice el modelo RPN 
descrito en la Sección 30.1.3 para recomendar cambios en el 
proceso con la intención de hacerlo más eficiente. 


30.2. Realice una investigación acerca de la eficaciade la rein- 
genieríade procesos de negocios. Presente argumentos a favor 
y en contra de este enfoque. 


30.3. Su profesor seleccionará uno de los programas que haya 
desarrollado alguien de la clase durante el curso. Intercambie 
su programa aleatoriamente con cualquier otra persona de la 
clase. No le explique ni revise el programa. A continuación, 
implemente una mejora (especificada por el instructor) en el 
programa que haya recibido. 

a. Lleve a cabo todas las tareas de ingeniería del software 
incluyendo una breve revisión (pero no con el autor del 
programa). 

Lleve la cuenta cuidadosamentede todos los erroresencon- 
trados durante la comprobación. 


€. Describa su experiencia en clase. 


30.4. Explore la lista de comprobación del análisis de inventa- 
rio presentada en el sitio Web SEPA e intente desarrollarun sis- 
tema de evaluación cuantitativodel softwareque sepueda aplicar 
alos programasexistentes en un esfuerzo de seleccionarlos pro- 
gramas candidatos para su reingeniería. Su sistema deberá ir 
más allá del análisiseconómico presentado en la Sección 30.6. 


30.5. Sugiera alternativas para el papel y el lápiz o para la 
documentación electrónica convencional que puedan servir 
como base para la reestructuración de documentos. [Pista: 
Piense en las nuevas tecnologías descriptivas que se podrían 
utilizar para comunicar el objetivo del software.] 


30.6. Algunas personas creen que las técnicas de inteligencia 
artificial incrementarán el nivel de abstracción de los proce- 
sos de ingeniería inversa. Efectúe una investigación sobre este 
tema (esto es, el uso de la IA para ingeniería inversa) y escri- 
ba un artículo breve que se decante por este tema. 


30.7. ¿Por qué es más difícil lograr la completitud a medida 
que el nivel de abstracción crece? 


30.8. ¿Por qué tiene que incrementarse la interactividad si es 
preciso incrementarse la completitud? 


30.9. Obtenga literatura de productos correspondientes a tres 
herramientas de ingeniería inversa y presente sus caracterís- 
ticas en clase. 


30.10. Existe una diferencia sutil entre la reestructuración y 
la ingeniería directa. ¿En qué consiste? 


30.11. Investigue en la literatura para hallar uno o dos artícu- 
los que describan casos prácticos de reingeniería de grandes 
computadoras para producir una arquitectura cliente/servidor. 
Presente un resumen. 


30.12. ¿Cómo se determinarían los valores de P, a P, en el 
modelo de costes y beneficios presentado en la Sección 30,6? 


Al igual que muchos tópicos candentes dentro de la comuni- 
dad de negocios, el bombo publicitario de la reingeniería de 
procesos de negocios ha dado pie a una visión más pragmáti- 
ca del tema. Hammer y Champy (Reengineering the Corpo- 
ration, HarperCollins, 1993) anticiparon gran interés por el 
tema con su best seller. Posteriormente, Hammer (Beyond 
Reengineering: How the Processed-Centered Organization is 
Changing Our Workand OurLives, Harper-Collins, 199/)refi- 
nó su visión centrándose en temas «centrados en procesos». 
Los libros de Andersen (Business Process Irnprovernent 
Toolhox, American Society for Quality, 1999), Harrington et 
al. (Business Process Improvement Workhook, McGraw-Hill, 
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1997), Hunt (ProcessMapping: How to Reengineer Your Busi- 
ness Processes, Wiley 1996), y Carr y Johanson (BestPrac- 
tices in Reengineering: What Works and WhatDoesn!'t in the 
Reengineering Process, McGraw-Hill, 1995) presentan casos 
prácticos y líneas generales detalladas para RPN. 

Feldmamn (ThePractical Guide to Business Process Reen- 
gineering Using IDEFO, Dorset House, 1998) estudia una 
notación modelada que ayuda en la RPN. Berztiss (Sofiare 
Methodsfor Business Reengineering, Springer, 1996) y Spurr 
y colaboradores (SoftwareAssistancefor Business Reengi- 
neering, Wiley, 1994) estudian las herramientas y técnicas 
que facilitan la RPN. 
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Relativamente pocos libros se han dedicado a la reingenie- 
ría del software. Rada (Reengineering Software: How to Reu- 
se Programming to Build New, State-Of-The-Art Software, 
Fitzroy Dearborn Publishers, 1999) se centra en la reinge- 
niería apn nivel técnico. Miller (Reengineering Legacy Soft- 
ware Systems, Digital Press, 1998) «proporciona un marco 
de trabajo para mantener los sistemas de aplicaciones sin- 
cronizados con las estrategias de negocios y con los cambios 
tecnológicos». Umar (Application(Re)Engineering: Building 
Web-BasedApplications and Dealing WithLegacies, Prentice 
Hall, 1997)proporciona una guía valiosa para aquellas orga- 
nizaciones que quieren transformar los sistemas antiguos en 
un entorno basado en Web. Cook (Building Enterprise Infor- 
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mation Architectures: Reengineering Information Systems, 
Prentice Hall, 1996) estudia el puente que existe entre RPN 
y la tecnología de información. Aiken (Data Reverse Engi- 
neering, McGraw-Hill, 1996) estudia cómo reclamar, reor- 
ganizar y reutilizar los datos de la organización. Arnold 
(Software Reengineering, IEEE Computer Society Press, 
1993) ha publicado una antología excelente de los primeros 
trabajos sobre las tecnologías de reingeniería del software. 

En Intemet se disponen de gran variedad fuentes de infor- 
mación sobre la reingeniería de procesos de negocios y la 
reingeniería del software. Una lista actualizada de referen- 
cias a sitios (páginas) web se puede encontrar en la dirección 
http: /www.pressman5.com. 
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INGENIERÍA DEL SOFTWARE 
ASISTIDA POR COMPUTADORA 


está tan ocupado haciendo zapatos para los demás que sus hijos no tienen sus propios 
zapatos. Antes de los años 90, muchos de los ingenieros de software fueron los hijos del 
zapatero. Aunque estos profesionales técnicos construyeron sistemas complejos y productos 
que automatizan los trabajos de otros, no utilizaron mucha automatización para ellos mismos. 

En la actualidad, los ingenieros de software han recibido por fin su primer par de zapatos 
nuevos —la ingeniería del software asistida por computadora (CASE)—. Los zapatos no vie- 
nen con tanta variedad como querrían, a veces son un poco duros y en algunos casos resultan 
incómodos, no proporcionan una sofisticación suficiente para los que los gustan de vestir bien, 
y no siempre coinciden con la ropa que utilizan los que desarrollan el software. Ahora bien, 
suponen una prenda absolutamente esencial en el guardarropa del que desarrolla el software y, 
con el tiempo, serán más cómodos, se utilizarán con más facilidad y se adaptarán mejor a las 
necesidades de cada uno de los desarrolladores. 

En los capítulos anteriores de este libro se ha intentado proporcionar una explicación razo- 
nable para comprender lo que sucede entre bastidores dentro de la tecnología de la ingeniería 
del software. En este capítulo, nuestro centro de interés se desplaza hacia las herramientas y 
entornos que ayudarán a automatizar el proceso del software. 


Y si. el mundo ha oído ese proverbio que habla de los hijos del zapatero: el zapatero 


VISTAZO RÁPIDO 


Qué es? Las herramient s CASE ayu- de trabajo o para realizar algún hito tie- 


niero del softw. ente producción de 


: dan a los gestores y practicantes de la 
“ingeniería del software en todas las 
actividades asociadas a los procesos 
de software. Automatizan las activida- 
des de gestión de proyectos, gestionan 
todos los productos de los trabajos ela- 
: borados a través del proceso, y ayudan 
alos ingenieros en el trabajo de análi- 
sis, diseño y codificación. Las herra- 
mientas CASE se pueden integrar 
dentro de un entorno sofisticado. 


, _ ¿Quién lo hace? Los gestores de pro- 


yectos y los ingenieros del software, 


¿Por qué es importante? La ingeniería 


del software es difícil. Las herramientas 
que reducen la cantidad de esfuerzo que 
se requiere para producir un producto 


ne un beneficio sustancial. Pero hay 
algo incluso más importante. Las herra- 
mientas pueden proporcionar nuevas 
formas de observar la información de la 
ingeniería del software —formas que 
mejoran la perspicacia del ingeniero 
que realiza el trabajo—. Esto conduce a 
tomar mejores decisiones y conseguir 
una calidad mejor del software, 


¿Cuáles son los pasos? CASE se utili- 


za junto con el modelo de procesos que 
se haya elegido, Si se dispone de un 
juego completo de herramientas, se uti- 
lizará CASE a lo largo de casi todos los 
pasos del proceso de software. 


¿Cuál es el producto obtenido? Las 


herramientas CASE ayudan al inge- 
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resultados de alta calidad. Además, 
disponer de automatización permite 
que el usuario de CASE elabore resul- 
tados adicionales y personalizados 
que no serán fáciles ni prácticos de 
producir sin el soporte de las herra- 
mientas. 


¿Cómo puedo estar seguro de que 


lo he hecho correctamente? Uti- 
lice las herramientas como comple- 
mento de las prácticas de ingeniería 
del sottware --—no como sustitutivo—. 
Antes de poder utilizar las herramien- 
tas eficazmente, deberán aprenderse 
los conceptos y métodos de la ingenie- 
ría del software. Solo entonces CASE 
proporcionará algún beneficio, 
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El mejor taller de un artesano —sea mecánico, carpin- 
tero o ingeniero del software — tiene tres característi- 
cas fundamentales: (1) una colección de herramientas 
útiles que le ayudarán en todos los pasos de la cons- 
trucción de un producto; (2) una disposición organiza- 
da que permitirá hallar rápidamente las herramientas y 
utilizarlas con eficacia; y (3) un artesano cualificado que 
entienda la forma de utilizar las herramientas de mane- 
ra eficaz. Ahora es cuando los ingenieros del software 
reconocen que necesitan más herramientas y más varia- 
das junto con un taller eficiente y organizado en el que 
puedan ubicarlas. 


La ingeniería del software asistida por computadora 
puede ser tan sencilla como una única herramienta que 
preste su apoyo para una única actividad de ingeniería 
del software, O tan compleja como todo un entorno que 
abarque «herramientas», una base de datos, personas, 
hardware, una red, sistemas operativos, estándares, y 
otros mil componentes más. Los bloques de construc- 
ción de CASE se ilustran en la Figura 31.1. Cada blo- 
que de construcción forma el fundamento del siguiente, 
estando las herramientas situadas en la parte superior 
del montón. Es interesante tener en cuenta que el fun- 
damento de los entornos CASE efectivos tiene relati- 
vamente poco que ver con las herramientas de ingeniería 
del software en sí. Más bien, los entornos para la inge- 
niería del software se construyen con éxito sobre una 
arquitectura de entornos que abarca un hardware y un 
software de sistemas adecuados. Además, la arquitec- 
tura del entorno deberá tener en cuenta los patrones de 
trabajo humano que se aplicarán durante el proceso de 
ingeniería del software. 


ás valiosos son aquellas 
información en el proceso de 


Las arquitecturas del entorno, que constan de una pla- 
taforma hardware y de un soporte de sistema operativo 
(incluyendo software de red, gestión de la base de datos 
y servicios de gestión de objetos), establece los cimien- 
tos para un entorno CASE. Pero el entorno CASE en sí 
requiere otros bloques de construcción. Existe un con- 
junto de servicios de portabilidad que proporciona un 
puente entre las herramientas CASE, su marco de inte- 
gración y la arquitectura del entorno. El marco de inte- 
gración es un grupo de programas especializados que 
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El taller de ingeniería del software se denomina un 
entorno de apoyo integrado a proyectos (que se des- 
cribirá posteriormente en este capítulo), y el conjunto 
de herramientas que llena ese taller se denomina inge- 
niería del software asistida por computadora (CASE). 

CASE proporciona al ingeniero la posibilidad de 
automatizar actividadesmanuales y de mejorar su visión 
general de la ingeniería. Al igual que las herramientas 
de ingeniería y de diseño asistidos por computadoraque 
utilizan los ingenieros de otras disciplinas, las herra- 
mientas CASE ayudan a garantizar que la calidad se 
diseñe antes de llegar a construir el producto. 


permiten a cada una de las herramientas comunicarse 
entre sí, para crear una base de datos del proyecto, y 
para mostrar el mismo aspecto al usuario final (el inge- 
niero del software). Los servicios de portabilidad per- 
miten que las herramientas CASE y su marco de 
integración migren entre distintas plataformas del hard- 
ware y sistemas operativos sin un mantenimiento adap- 
tativo significativo. 


Herramientas CASE 
Marco de integración 


s de portabilida 


FIGURA 31.1. Bloques de construcción CASE. 


Los bloques de construcción representados en la 
Figura 31.1 representan un fundamento completo para 
la integración de herramientas CASE. Sin embargo, la 
mayor parte de las herramientas CASE que se utilizan 
en la actualidad no han sido construidas empleando 
todos los bloques de construcción anteriormente des- 
critos. De hecho, algunas herramientas siguen siendo 
las «soluciones puntuales». Esto es, una herramientase 
utiliza para prestar apoyo en una actividad de ingenie- 
ría del software concreta (por ejemplo, modelado de 
análisis), pero esta herramienta no se comunica direc- 
tamente con otras, no está unida a una base de datos del 
proyecto, y no forma parte de un entorno integrado 
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CASE (1-CASE). Aunque esta situación no es la ideal, 
se puede utilizar una herramienta CASE bastante efi- 
ciente, aunque se trate de una solicitud puntual. 


Herramienta individual 
(solución puntual) 


Intercambio de datos 


Puentes y asociaciones 
entre herramientas 


FIGURA 31.2. Opciones integradas. 


Los niveles relativos de integración CASE se mues- 
tran en la Figura 3 1.2. En el extremo inferior del espec- 
tro de integración se encuentrala herramienta individual 
(solución puntual). Cuando las herramientas individuales 
proporcionan servicios para el intercambio de datos 
(como lo hacen la mayoría), el nivel de integración mejo- 
ra ligeramente. Estas herramientas producen su salida 
en un formato estándar que deberá ser compatible con 
otras herramientas que sean capaces de leer ese forma- 
to. En algunos casos, los constructores de herramientas 
CASE complementarias trabajanjuntos para formar un 
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puente entre herramientas (por ejemplo, una herramienta 
de análisis y diseño que se enlaza con un generador de 
código). Mediante la utilización de este enfoque, la siner- 
gia entre herramientas puede producir unos resultados 
finales que serían difíciles de crear empleando cada una 
de las herramientas por separado. La integración de 

fuente única se produce cuando un único vendedor de 
herramientas CASE integra una cierta cantidad de herra- 
mientas distintas y las vende en forma de paquete. Aun- 
que este enfoque es bastante eficiente, la arquitectura 
cerrada de la mayoría de los entornos de fuente Única 
evita añadir fácilmente herramientas procedentes de 
otros fabricantes. 


o 


las herramientas CASE de solución puntual pueden 
proporcionar un beneficio sustancia, pero un equipa de 
software necesita herramientas que se comuniquen entre 
si. las herramientas integradas ayudan a que el equipa 
desarrolle, organicey controlelos proouctos del trabaja. 
Utilícelos. 


En el extremo superior del espectro de integración 
se encuentra el entorno de apoyo integrado a proyec- 
tos integrado (EAIP). Se han creado estándares en cada 
uno de los bloques de construcción descritos anterior- 
mente. Los fabricantes de herramientas CASE utilizan 
los estándares EAIP para construir herramientas que 
sean compatibles con el EAIP, y que por tanto sean com- 
patibles entre sí. 


Existe un cierto número de riesgos que son inherentes 
siempre que se intenta efectuar una categorización de 
las herramientas CASE. Existe una sutil implicación que 
consiste en que para crear un entorno CASE efectivo se 
deberán implementar todas las categorías de herramientas 
—esto no es ni sencillo, ni cierto —. Cuando hay perso- 
nas que creen que una herramienta pertenece a una cate- 
goría, se puede crear cierta confusión (o contradicción) 
al ubicar una herramientaespecíficadentro de otra cate- 
goría. Es posible que algunos lectores piensen que se ha 
omitido una categoría completa —eliminando por tan- 
to un conjunto de herramientas completo e incluirlo así 
en el entorno CASE global —. Además, una categoriza- 
ción sencilla tiende a ser plana - estoes, no se muestra 
la interacciónjerárquica de las herramientas o las rela- 
ciones que existen entre ellas —. A pesar de estos ries- 
gos, es necesario crear una taxonomía de herramientas 
CASE —para comprender mejor la amplitud de CASE 
y para apreciar mejor en donde se pueden aplicar estas 
herramientas dentro del proceso del software —. 

Las herramientas CASE se pueden clasificar por su 
función, por su papel como instrumentos para admi- 
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nistradores o personal técnico, por su utilización en los 
distintos pasos del proceso de ingeniería del software, 
por la arquitectura del entorno (hardware y software) 
que les presta su apoyo, o incluso por su origen o cos- 
te [QED89]. La taxonomía que se presenta a continua- 
ción utiliza como criterio principal la función. 


Herramientas CASE 


Herramientas de ingeniería de procesos de nego- 
cio. Al modelar los requisitos de información estraté- 
gica de una organización, las herramientas de ingeniería 
de procesos de negocios proporcionan un «metamo- 
delo» del cual se derivan sistemas de información espe- 
cíficos. En lugar de centrarse en los requisitos de una 
aplicación específica, estas herramientas CASE mode- 
lan la información de negocio cuando ésta se transfiere 
entre distintas entidades organizativasen el seno de una 
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compañía. El objetivo primordial de las herramientas 
de esta categoría consiste en representar objetos de datos 
de negocio, sus relaciones y la forma en que fluyen estos 
objetos de datos entre distintas zonas de negocio en el 
seno de la compañía. 


Referencia cruzada 


La ingeniería de procesos de negocios se trato 
en el Capítulo 10. 


Modelado de procesos y herramientas de gestión. 
Si una organización trabaja por mejorar un proceso de 
negocio (o de software) lo primero que debe hacer es 
entenderlo. Las herramientas de modelado de procesos 
(llamadas también herramientas de tecnología de pro- 
cesos) se utilizan para representar los elementos clave 
del proceso de manera que sea posible entenderlo mejor. 
Estas herramientas también pueden proporcionar víncu- 
los con descripciones de procesos que ayuden a quienes 
estén implicados en el proceso de comprenderlas tareas 
que se requieren para llevar a cabo ese proceso. Además, 
las herramientas de gestión de procesos pueden propor- 
cionar vínculos con otras herramientas que proporcionan 
un apoyo para las actividadesde proceso ya definidas. 


los elementos de procesos del software se traton 
en el Capítulo 2. 


Herramientas de planificación de proyectos. Las 
herramientas de esta categoría se centran en dos áreas 
primordiales: estimación de costes y de esfuerzos del 
proyecto de software y planificación de proyectos. Las 
herramientas de estimación calculan el esfuerzo esti- 
mado, la duración del proyecto y el número de perso- 
nas recomendado para el proyecto. Las herramientas 
de planificación de proyectos hacen posible que el ges- 
tor defina todas las tareas del proyecto (la estructura 
de desglose de tareas), que cree una red de tareas (nor- 
malmente empleando una entrada gráfica), que repre- 
sente las interdependencias entre tareas y que modele 
la cantidad de paralelismo que sea posible para ese 
proyecto. 


Referencia cruzada 


los técnicas de estimación se presentan en el Capitulo 5. 
los métodos de planticaciónse tratan en el Capítulo 7. 


Herramientas de análisis de riesgos. La identifi- 
cación de posibles riesgos y el desarrollo de un plan 
para mitigar, monitorizar y gestionar esos riesgos tiene 
una importancia fundamental en los proyectos grandes. 
Las herramientas de análisis de riesgos hacen posible 
que el gestor del proyecto construya una tabla de ries- 
gos proporcionando una guía detallada en la identifica- 
ción y análisis de riesgos. 
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Referencia cruzada 


El análisis y gestión de riesgos se hato 
en el Capitulo 6. 


Herramientas de gestión de proyectos. La planifi- 
cación del proyecto y el plan del proyecto deberán ser 
rastreados y monitorizados de forma continua. Además, 
el gestor deberá utilizar las herramientas que recojan 
métricas que en Última instancia proporcionen una indi- 
cación de la calidad del producto del software. Las herra- 
mientas de esta categoría suelen ser extensiones de 
herramientas de planificación de proyectos. 


El seguimiento y lo monitorización se tratan 
en el Capitulo 7. 


Herramientas de seguimiento de requisitos. 
Cuando se desarrollan grandes sistemas, las cosas «se 
derrumban». Es decir, el sistema proporcionado suele 
no satisfacer los requisitos especificados por el cliente. 
El objetivo de las herramientas de seguimiento es pro- 
porcionar un enfoque sistemático para el aislamiento de 
los requisitos, comenzando por el RFP del cliente o por 
la especificación. Las herramientas típicas de segui- 
miento de requisitos combinan una evaluación de tex- 
tos por interacción humana, con un sistema de gestión 
de bases de datos que almacena y categoriza todos y 
cada uno de los requisitos del sistema que se «analizan» 
a partir de la RFP o especificación original. 


Referencia cruzada 


Los métodos de ingeniería de requisitos se tratan 
en el Capitulo 10. 


Herramientas de métricas y de gestión. Las métri- 
cas del software mejoran la capacidad del gestor para 
controlar y coordinar el proceso de ingeniería del soft- 
ware y la capacidad del ingeniero para mejorar la cali- 
dad del software que se produce. Las métricas o 
herramientas de medidas actuales se centran en caracte- 
rísticas de procesos y productos. Las herramientas orien- 
tadas a la gestión se sirven de métricas específicas del 
proyecto (por ejemplo, LDC/persona-mes, defectos por 
punto de función) que proporcionan una indicación glo- 
bal de productividad o de calidad. Las herramientas con 
orientacióntécnica determinan las métricas técnicas que 
proporcionan una mejor visión de la calidad del diseño 
o del código. 


Referencia cruzada 


Los métricas se presentan en los Capítulos 4, 19 y 24, 


Herramientas de documentación. Las herramien- 
tas de producción de documentos y de autoedición pres- 


www.elsolucionario.net 


CAPÍTULO 31 INGENIERÍA DEL SOFTWARE ASISTIDA POR COMPUTADORA 


tan su apoyo a casi todos los aspectos de la ingeniería 
del software, y representan una importante oportunidad 
de «aprovechamiento» para todos los que desarrollan 
software. La mayoría de las organizaciones dedicadas 
al desarrollo de software invierten una cantidad de 
tiempo considerable en el desarrollo de documentos, y 
en muchos casos el proceso de documentación en sí 
resulta bastante deficiente. Es frecuente que una orga- 
nización de desarrollo de software invierta en la docu- 
mentación hasta un 20 o un 30 por 100 de su esfuerzo 
global de desarrollo de software. Por esta razón, las 
herramientas de documentación suponen una oportuni- 
dad importante para mejorar la productividad. 


lo documentación se estudia a lo largo de todo el 
libro. En SepaWeb se presentan más datos. 


Herramientas de software de sistema. CASE es 
una tecnología de estaciones de trabajo. Por tanto, el 
entorno CASE deberá adaptarse a un software de sis- 
tema en red de alta calidad, al correo electrónico, a los 
tablones de anuncios electrónicos y a otras posibilida- 
des de comunicarse. 


Consulte los Capítulos27, 28 y 29 poro un estudio 
limitado de estos temas. 


Herramientas de control de calidad. La mayor 
parte de las herramientas CASE que afirman tener 
como principal interés el control de calidad son en rea- 
lidad herramientas de métricas que hacen una audito- 
ría del código fuente para determinar si se ajusta o no 
a ciertos estándares del lenguaje. Otras herramientas 
extraen métricas técnicas (Capítulos 19 y 24) en un 
esfuerzo por extrapolar la calidad del software que se 
está construyendo. 


6 CS se presenta en el Capítulo 8. 


Herramientas de gestión de bases de datos. El soft- 
ware de gestión de bases de datos sirve como funda- 
mento para establecer una base de datos CASE 
(repositorio), que también se denominará base de datos 
del proyecto. Dada la importancia de los objetos de con- 
figuración, las herramientas de gestión de bases de datos 
para CASE pueden evolucionar a partir de los sistemas 
de gestión de bases de datos relacionales (SGBDR) para 
transformarse en sistemas de gestión de bases de datos 
orientadas a objetos (SGBDOO). 
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Referencia cruzada 


El repositorio de sofiwdra sa. estudio en el Capítulo 9. 


Herramientas de gestión de configuración de soft- 
ware. La gestión de configuraciónde software (GCS) se 
encuentra en el núcleo de todos los entornos CASE. Las 
herramientas pueden ofrecer su asistencia en las cinco 
tareas principalesde GCS — identificación, control de ver- 
siones, control de cambios, auditoría y contabilidad de 
estados —. La base de datos CASE proporciona el meca- 
nismo de identificartodos los elementos de configuración 
y derelacionarlocon otros elementos;el proceso de con- 
trol de cambios se puede implementar con ayuda de las 
herramientas especializadas;un acceso sencillo a los ele- 
mentos de configuración individuales facilita el proceso 
de auditona; y las herramientas de comunicación CASE 
pueden mejorar enormemente la Contabilidad de estados 
(ofreciendo información acerca de los cambios a todos 
aquellos que necesiten conocerlos). 


Los actividades 6CS en donde se incluyen 
lo.identíficación, control.de versiones, control 
de cambios, auditoría, y contabilidad de estados 
se estudion en el Copítulo 9. 


Herramientas de análisis y diseño. Las herra- 
mientas de análisis y diseño hacen posible que el inge- 
niero del software cree modelos del sistema que vaya a 
construir. Los modelos contienen una representación de 
los datos, función y comportamiento (en el nivel de aná- 
lisis), así como caracterizaciones del diseño de datos, 
de arquitectura, a nivel de componentes e interfaz'. Al 
efectuar una comprobación de consistencia y validez de 
los modelos, las herramientas de análisis y diseño pro- 
porcionan al ingeniero del software un cierto grado de 
visión en lo tocante a la representación del análisis, y 
le ayudan a eliminar errores antes de que se propaguen 
al diseño, o lo que es peor, a la propia implementación. 


Referencia cruzada 


Eonálisis y el diseño se estudian en las Partes 
Tercera y Cuarto de este libro. 


HerramientasPRO/SIM. Las herramientas PRO/SIM 
(de construcción de prototipos y simulación) [NIC90] pro- 
porcionan al ingeniero del software la capacidad de pre- 
decir el comportamiento de un sistema en tiempo real 
antes de llegar a construirlo. Además, también le capaci- 
tan para desarrollar simulaciones del sistema de tiempo 
real, lo que permitirá que el cliente obtenga ideas acerca 
de su funcionamiento, comportamientoy respuesta antes 
de la verdadera implementación. 


U La herramientas de diseño y de análisis orientado a objetos pro- 
porcionan representaciones análogas. 
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Referencia cruzada 


Lo construcción de prototiposy la simulación 
se estudian brevementeen el Capitulo 10. 


Herramientas de desarrollo y diseno de interfaz. Las 
herramientas de desarrollo y diseño de interfaz son en rea- 
lidad un conjunto de herramientas de componentes de pro- 
gramas (clases) tales como menús, botones, estructurasde 
ventanas, iconos, mecanismos de desplazamiento de la 
pantalla, controladores de dispositivos, etc. Sin embargo, 
estos conjuntos de herramientas se están viendo sustitui- 
dos por herramientas de construcciónde prototiposde inter- 
faz que permiten una rápida creación en pantalla de 
interfaces de usuario sofisticadas,que se ajustan al están- 
dar de interfaz que se haya adoptado para el software. 


los elementos del diseño de interfaz de usuario 
se presentan en el Copítulo 15, 


Herramientas de construcción de prototipos. Se 
puede utilizar toda una gama de herramientas de cons- 
trucción de prototipos. Los generadores de pantallas per- 
miten al ingeniero del software definir rápidamente la 
disposición de la pantalla para aplicacionesinteractivas. 
Otras herramientas de prototipos CASE más sofisticadas 
permiten la creación de un diseño de datos, acompañado 
por diseños e informes de la pantalla. Muchas herra- 
mientas de análisis y diseño son más extensas y propor- 
cionan opciones de construcción de prototipos. Las 
herramientas PRO/SIM generan un diseño esquemático 
de código fuente en Ada y C para las aplicaciones de inge- 
niería (en tiempo real). Por último, una gama amplia de 
herramientas de cuarta generación poseen también carac- 
terísticas de construcción de prototipos. 


lo construcciónde prototiposse estudio 
enlos Copítulos 2 y 11, 


Herramientas de programación. La categoría de 
herramientas de programación abarca los compilado- 
res, editores y depuradores disponibles para apoyar a la 
mayoría de los lenguajes de programación convencio- 
nales. Además, en esta categoría también residen los 
entomos de programación orientados a objetos (OO), 
los lenguajes de cuarta generación, los entomos de pro- 
gramación gráfica, los generadores de aplicaciones y 
los lenguajes de consulta de bases de datos. 


Herramientas de desarrollo de Webs. Las activi- 
dades asociadas a la ingeniería Web están apoyadas por 
una variedad de herramientas de desarrollo de WebApps. 
Entre estas herramientas se incluyen las que prestan 
ayuda en la generación de texto, gráficos, formularios, 
guiones, applets y otros elementos de una página Web. 
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Referencia cruzada 


I-WEB se estudia en el Capítulo 29 


Herramientas de integración y pruebas. En el 
directorio de herramientas de pruebas de software del 
Software Quality Engineering [SQE95], se definen las 
categorías de herramientas de pruebas siguientes: 

» adquisición de datos: herramientas que adquieren 
los datos que se utilizarán durante la prueba; 

+ medida estática: herramientas que analizan el código 
fuente sin ejecutar casos de prueba; 


La comprobación del software se astudia 
en los Capítulos 17, 18-y 23 -osí como en los 
Copítulos 28 y 29. 


+ medida dinámica: herramientas que analizan el 
código fuente durante la ejecución; 

+ simulación: herramientas que simulan las funciones 
del hardware o de otros elementos externos; 

+ gestión depruebas: herramientas que prestan su asis- 
tencia en la planificación, desarrollo y control de las 
pruebas; 

. herramientas defuncionalidad cruzada: se trata de 
herramientas que atraviesan los límites de las cate- 
gorías anteriores. 


Debería tenerse en cuenta que muchas de las herra- 
mientas de prueba poseen características que abarcan 
dos categorías o más de las anteriormente mencionadas. 


Herramientas de análisis estático.Las herramientas 
de análisis estático prestan su asistencia al ingeniero del 
software a efectos de derivar casos prácticos. En la indus- 
tria se utilizan tres tipos distintos de herramientas estáti- 
cas de prueba: herramientas de prueba basadas en código; 
lenguajes de prueba especializados y herramientas de 
prueba basadas en requisitos. Las herramientas de prueba 
basadas en código admiten un código fuente (o LDP) 
como entrada, y llevan a cabo varios análisis de los que 
se obtiene la generación de casos de prueba. Los lengua- 
jes deprueba especializados (porejemplo, ATLAS) hacen 
posible que el ingeniero del software escriba especifica- 
ciones de prueba detalladas para describir todos los casos 
de prueba y la logística de su ejecución. Las herramien- 
tas de prueba basadas en requisitos aíslan los requisitos 
del usuario y sugieren los casos de prueba (o clases de 
prueba) que ejercitaránesos requisitos. 


Los métodos de comprobación de cap negra 
se estudian en el Capítulo 17, 


Herramientas de análisis dinámico. Las herra- 
mientas de análisis dinámico interactúan con el pro- 
grama que se esté ejecutando, prueban la cobertura de 
rutas, prueban las afirmaciones acerca del valor de varia- 
bles específicas e instrumentan por otro lado el flujo de 
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ejecución del programa. Las herramientas dinámicas 
pueden ser intrusivas, O no intrusivas. Las herramien- 
tas intrusivas modifican el software que hay que com- 
probar mediante la inserción de sondas (instrucciones 
adicionales) y que efectúan las actividades menciona- 
das anteriormente.Las herramientas de prueba no intru- 
sivas utilizan un procesador hardware por separado que 
funciona en paralelo con el procesador que contiene el 
programa que se está probando. 


Herramientas de gestión de pruebas. Las herra- 
mientas de gestión de pruebas se utilizan para controlar 
y coordinar las pruebas del software por todos y cada uno 
de los pasos principales de las pruebas. Las herramien- 
tas de esta categoría gestionan y coordinan las pruebas 
de regresiones, efectúan comparaciones que determinan 
las diferencias entre la salida real y la esperada y reali- 
zan pruebas por lotes de programas con interfaces hom- 
bre-máquina interactivas. Además de las funciones 
indicadas anteriormente, muchas herramientas de ges- 
tión de pruebas sirven también como controladores de 
pruebas genéricos. Un controlador de pruebas lee uno o 
más casos de prueba de algún archivo de pruebas, aplica 
formato a los datos de prueba para que se ajusten a las 
necesidades del software que se está probando, e invoca 
entonces al software que es preciso probar. 


Las estrategiasde prueba se estudion 
en el Capítulo 18. 


Herramientas de pruebas cliente/servidor. El 
entorno C/S exige unas herramientas de pruebas espe- 
cializadas que ejerciten la interfaz gráfica de usuario 
y los requisitos de comunicacionesen red para el cliente 
y el servidor. 
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la prueba(/S se estudia en el Capítulo.28. 


Herramientas de reingeniería. Las herramientas 
para el software heredado abarca un conjunto de activi- 
dades de mantenimientoque actualmente absorben un 
porcentaje significativode todo el esfuerzo relacionado 
con el software. La categoría de herramientas de rein- 
geniería se puede subdividiren las funciones siguientes: 


herramientas de ingeniería inversa para producir 
especificaciones: se toma el código fuente como 
entrada y se generan modelos gráficos de análisis y 
diseño estructurados, listas de utilización y más infor- 
mación sobre el diseño; 
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los métodosde reingeniería se estudian 
en el Capítulo 30. 


herramientas de reestructuración y análisis de 
código: se analiza la sintaxis del programa, se genera 
una gráfica de control de flujo y se genera automá- 
ticamente un programa estructurado; y 


herramientas de reingeniería para sistemas on- 
line: se utilizan para modificar sistemas de bases 
de datos on-line (por ejemplo, para convertir archi- 
vos IDMS o DB2 en un formato de entidades y 
relaciones). 


Muchas de las herramientas anteriores se ven limi- 
tadas a lenguajes de programación específicos (aunque 
abarcan la mayoría de los lenguajes principales) y 
requieren un cierto grado de interacción con el inge- 
niero del software. 


Aunque se pueden obtener beneficios individualmen- 
te de las herramientas CASE que abarcan actividades 
de ingeniería del software por separado, la verdadera 
potencia de CASE solamente se puede lograr median- 
te la integración. Entre los beneficios del CASE inte- 
grado (1-CASE) se incluyen: (1) una transferencia 
regular de información (modelos, programas, docu- 
mentos, datos) entre una herramienta y otra, y entre 
un paso de ingeniería y el siguiente; (2) una reducción 
del esfuerzo necesario para efectuar actividades glo- 
bales tales como la gestión de configuración de soft- 
ware, el control de calidad y la producción de 
documentos; (3) un aumento del control del proyecto 
que se logra mediante una mejor planificación, moni- 
torización y comunicación; (4) una mejor coordina- 
ción entre los miembros del personal que estén 
trabajando en grandes proyectos de software. 
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¿Cuáles son los beneficios 
de CASE integradas? 


Ahora bien, 1-CASEtambién expone a desafíos sig- 
nificativos. En cada acción exige unas representaciones 
consecuentes de la información de la ingeniería del 
software; unas interfaces estandarizadas entre las herra- 
mientas, un mecanismo homogéneo para la comuni- 
cación entre el ingeniero del software y todas sus 
herramientas, y un enfoque efectivo que hará posible 
que 1-CASE se desplace a lo largo de distintas plata- 
formas de hardware y distintos sistemas operativos. Los 
entornos 1-CASE generales han comenzadoa surgir más 
lentamente de lo que inicialmente se esperaba. Sin 
embargo, los entornos integrados sí que existen, y con 
el paso de los años se van haciendo más poderosos. 
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e 
Lave 
la integraciónde los herramientas CASE exige uno base 


de datos que contenga las representacionesconsecuentes 
de la información de la ingenierío del softwore. 


El término integración implica tanto combinación 
como cierre. 1-CASEcombina toda una gama de herra- 
mientas e información distintos de tal modo que hace 
posible el cierre de la comunicación entre las herra- 
mientas, entre personas y entre procesos de software. 
Las herramientas se integran de tal manera que la infor- 
mación de ingeniería del software esté disponible para 
todas las herramientas que se necesiten; la utilización 
se integra de tal modo que se proporciona un aspecto y 
una interacción común para todas las herramientas; y 
se integra una filosofía de desarrollo que aplica prácti- 
cas modernas y métodos ya probados. 

Para definir la integración en el contexto del proce- 
so del software, es necesario establecer un conjunto de 
requisitos para 1-CASE[FOR89a]. Un entorno CASE 
integrado debería: 
proporcionar un mecanismo para compartir la infor- 
mación de la ingeniería del software entre todas las 
herramientas dentro del entorno; 
hacer posible que un cambio de un elemento de infor- 
mación se siga hasta los demás elementos de infor- 
mación relacionados; 
proporcionar un control de versiones y una gestión 
de configuración general para toda la información de 
la ingeniería del software; 


permitir un acceso directo y no secuencial a cual- 
quier herramienta del entorno; 


establecer un apoyo automatizado para el modelo de 
procesos de software que se haya seleccionado, inte- 
grando herramientas CASE y elementos de configu- 
ración del software en una estructura estándar de 
desglose de trabajo; 


permittr que los usuarios de cada una de las herra- 
mientas puedan experimentar con el aspecto e inte- 
racción de la interfaz hombre-máquina; 


Referencia cruzada 


los temos relacionados con los procesos se estudian 
en los Capítulos 2,4 y 7. Los E(s se presentan 
en el Capítulo 9, 


dar soporte a la comunicación entre ingenieros del 
software; y 


recoger métricas tanto técnicas como de gestión que 
se puedan utilizar para mejorar el proceso y el pro- 
ducto. 


Para alcanzar estos objetivos, cada uno de los blo- 
ques de construcción de una arquitectura (CASE 
—Fig. 31.1> deberá encajar con los demás sin nin- 
gún tipo de limitación. Los bloques de construcción 
fundamentales — arquitecturadel entorno, plataforma 
hardware y sistema operativo — deberán «unirse» a 
través de uñ conjunto de servicios de portabilidad a un 
marco de referencia de integración que alcance los 
objetivos indicados anteriormente. 


Un equipo de ingeniería del software utiliza herra- 
mientas CASE, los métodos correspondientes y un 
marco de referencia de proceso con objeto de crear 
un conjunto de informaciones de ingeniería del soft- 
ware. El marco de referencia de integración facilita 
la transferencia de información desde y hacia ese con- 
junto de informaciones. Para lograr esto, deberán 
existir los componentes de arquitectura siguientes: la 
creación de una base de datos (para almacenar la 
información); la construcción de un sistema de ges- 
tión de objetos (para gestionar los cambios efectua- 
dos en la información); la construcción de un 
mecanismo de control de herramientas (para coordi- 
nar la utilización de herramientas CASE), y una inter- 
faz de usuario que proporcione una ruta consecuente 
entre las acciones efectuadas por el usuario y las 
herramientas que están dentro del entorno. La mayo- 
ría de los modelos (por ejemplo, [FOR90], [SHA95] 
del marco de referencia de integración representan a 
estos componentes como si fueran capas. En la Figu- 
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ra 31.3. se muestra un modelo sencillo del marco de 
referencia que representa únicamente los componen- 
tes indicados anteriormente. 


Una lista de todos los elementos de información 
de la ingeniería del software puede encontrarse 
bolo los Els. 


La capa de interfaz del usuario (Figura 31.1) incor- 
pora un conjunto de herramientas de interfaz estanda- 
rizado, con un protocolo de presentación común. El kit 
de herramientas de interfaz contiene software para la 
gestión de la interfaz hombre-máquina, y una bibliote- 
ca de objetos de visualización. Ambos proporcionan un 
mecanismo consecuente para la comunicación entre la 
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interfaz y las herramientas CASE individuales. El pro- 
tocolo de presentación es el conjunto de líneas gene- 
rales que proporciona un mismo aspecto a todas las 
herramientas CASE. Las convenciones del diseño de 
pantalla, nombres y organización del menú, iconos, 
nombres de los objetos, utilización del teclado y del 
ratón, y el mecanismo para acceder a las herramientas 
se definen todos ellos como parte del protocolo de pre- 
sentación. 


Capa de interfaz de usuario 
Kit de herramientas de interfaz 
Protocolo de presentación 


Servicios de gestión de herramientas 


Capa de herramientas 


n de objetos 


3 Pe 
s de integración 


icios de gestión de configuració 


FIGURA 31.3. Modelo de arquitectura para el marco 
de referencia de integración. 


La capa de herramientas incorpora un conjunto de 
servicios de gestión de herramientas con las herra- 
mientas CASE en sí. Los servicios de gestión de herra- 
mientas (SGH) controlan el comportamiento de las 
herramientas dentro del entorno. Si durante la ejecu- 
ción de una o más herramientas se emplea la multita- 
rea, SGH efectúa la sincronización y comunicación 


INGENIEHIA DEL SUFIWAKE ASISTIDA POR COMPUTADORA 


multitarea, coordina el flujo de información desde el 
repositorio y el sistema de gestión de objetos a las 
herramientas, realiza las funciones de seguridad y audi- 
toría y recoge métricas acerca de la utilización de herra- 
mientas. 


Referencia Web 


los recursos paro la integraciónde herramientas CASE 
y poro los Entornos de Integración de Ingeniería 

del software se pueden obtener en: 
see.cs.flinders.edu.au/seweb/ti/ 


La capa de gestión de objetos (CGO) lleva a cabo 
las funciones de gestión de configuración que se des- 
cribían en el Capítulo 8. En esencia, el software de esta 
capa de la arquitectura de marco de referencia propor- 
ciona el mecanismo para la integración de herramien- 
tas. Cada herramienta CASE «se enchufa» en la capa 
de gestión de objetos. Al funcionar en conjunto con el 
repositorio CASE, la CGO proporciona los servicios de 
integración —un conjuntode módulos estándar que aco- 
plan las herramientas con el repositorio—. Además, la 
OML proporciona los servicios de gestión de configu- 
ración haciendo posible la identificación de todos los 
objetos de configuración, llevando a cabo el control de 
versiones y proporcionando apoyo para el control de 
cambios, auditorías y contabilidad de estados. 

La capa de repositorio compartido es la base de datos 
CASE y las funciones de control de acceso que hacen 
posible que la capa de gestión de objetos interactúe con 
la base de datos. La integración de datos se logra 
mediante las capas de gestión de objetos y de reposito- 
rio compartido que se estudian más adelante y con más 
profundidad en este mismo capítulo. 


El Diccionario Websterdefine la palabra repositoriocomo 
«todo objeto o persona considerado centro de acumula- 
ción o almacenamiento». Durante las primeras fases de la 
historia del desarrollo del software, el repositorio era en 


realidad una persona el programador que tenía que recor- 
dar la ubicación de toda la información relevante para un 
determinado proyecto de software, que tenía que recordar 
información que nunca se había escrito y que tenía que 
reconstruir la información que se había perdido —. Triste- 
mente, la utilización de una personacomo «centro de acu- 
mulación y almacenamiento» (aunque corresponda con la 
definición del diccionario) no funciona demasiado bien. 
En la actualidad, el repositorio es una «cosa» —una base 
de datos que actúa como centro tanto para la acumulación 
como para el almacenamientode información de ingenie- 
ría del software —. El papel de la persona (del ingeniero 
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del software) es interactuar con el repositorio empleando 
herramientas CASE integradas con él, 

En este libro, se utiliza un determinado número de 
términos distintos para hacer alusión al lugar de alma- 
cenamiento de la información de la ingeniería del soft- 
ware: base de datos CASE, base de datos del proyecto, 
base de datos de entorno de apoyo integrado a proyec- 
to (EAIP), diccionario de requisitos (una base de datos 
limitada) y repositorio, Aunque existen sutiles diferen- 
cias entre algunos de estos términos todos ellos hacen 
referencia al centro de acumulación y almacenamiento. 


31.6.1. El papel del repositorio en 1-CASE 


El repositorio de un entorno 1-CASEes el conjunto de 
mecanismos y de estructuras de datos que consiguen la 
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integración entre datos y herramientas, y entre datos y 
datos. Proporciona las funciones obvias de un sistema 
de gestión de bases de datos, pero, además, el reposito- 
rio lleva a cabo o precipita las funciones siguientes 
[FORS89b]: 


integridad de datos: incluye funciones para validar 
las entradas efectuadas en el repositorio, para asegu- 
rar la consistencia entre objetos relacionados, y para 
efectuar automáticamente modificaciones «en cas- 
cada» cuando un cambioefectuado en un objeto exige 
algún cambio en otros objetos relacionados con él; 


información compartida: proporciona un mecanismo 
para compartir información entre múltiples desarro- 
lladores y entre múltiples herramientas; gestiona y 
controla el acceso multiusuario a los datos, y blo- 
quea/desbloquea objetos para que los cambios no se 
superpongan inadvertidamente; 


; ¿Cales son las funciones que 
llevan a cabo los servicios que 
se acoplan con el repositorio CASE? 


integración datos-herranzientas:estableceun modelo 
de datos al que pueden acceder todas las herramien- 
tas del entorno 1-CASE; controla el acceso a los 
datos, y lleva a cabo las funciones de gestión de con- 
figuración adecuadas; 


integración duros-datos: el sistema de gestión de 
bases de datos relaciona los objetos de datos de tal 
manera que se puedan alcanzar las demás funcio- 
nes; 

imposición de la metodología: el modelo E-R de 
datos almacenado en el repositorio puede implicar 
un paradigma específico de ingeniería del software; 
como mínimo, las relaciones y los objetos definen 
un conjunto de pasos que se llevará a cabo para cons- 
truir el contenido del repositorio; 


estandarizaciónde documentos: la definición de obje- 
tos de la base de datos da lugar directamente a un 
enfoque estándar para la creación de documentos de 
ingeniería del software. 


Para conseguir estas funciones, se define el reposi- 
torio en función de un metamodelo. El metamodelo 
determina la forma en que se almacena la información 
en el repositorio, la forma en que las herramientas pue- 
den acceder a los datos y estos datos pueden ser visua- 
lizados por los ingenieros de software, el grado hasta el 
cual se puede mantener la seguridad e integridad de los 
datos, y la facilidad con que se puede ampliar el mode- 
lo ya existente para admitir nuevas necesidades 
[WEL389]. 

El metamodelo es la plantilla en la cual se sitúa la 
información de ingenieríadel software. Una descripción 
detallada de estos modelos va más allá del alcance de este 
libro. Para más información, el lector interesado podría 
consultar[WEL89], [SHA95] y [GRI95]. 
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31.6.2. Características y contenidos 


Las características y contenido del repositorio se entien- 
den especialmente bien examinándolo desde dos pers- 
pectivas: ¿Qué es lo que hay que almacenar en el 
repositorio, y qué servicios específicos son los que pro- 
porciona el repositorio? En general, los tipos de cosas 
que habrá que almacenar en el repositorio incluyen: 


el problema que hay que resolver; 


información acerca del dominio del problema; 


la solución del sistema a medida que va surgiendo; 


las reglas e instrucciones relativas al proceso de soft- 
ware (metodología) que se está siguiendo; 
el plan del proyecto, sus recursos y su historia; 


información acerca del contexto organizativo. 


En la Tabla 31.1 se ha incluido una lista detallada de 
tipos de representaciones, documentos y otros produc- 
tos que se almacenan en el repositorio CASE. 

Un repositorio CASE robusto proporciona dos cla- 
ses distintas de servicios: (1) los mismos tipos de ser- 
vicios que puede uno esperar de cualquier sistema de 
gestiórfde bases de datos sofisticados; y (2) servicios 
que son específicos del entorno CASE. 

Muchos requisitos del repositorio son iguales a los 
de las aplicaciones típicas que se construyen tomando 
como base un sistema de gestión de bases de datos de 
comercial (SGBD). De hecho, muchos de los reposito- 
rios CASE actuales hacen uso de un SGBD (normal- 
mente relacional u orientado a objetos) como la 
tecnología de gestión de datos básica. Entre las carac- 
terísticas de un SGBD que dan soporte a la gestión de 
información de desarrollo del software se incluyen las 
siguientes: 


Almacenamiento de datos no redundante. Cada 
objeto es almacenado sólo una vez, aunque es accesi- 
ble por todas las herramientas CASE siempre y cuando 
estas lo necesiten. 


Acceso de alto nivel. Se implementa un mecanismo 
común de acceso a los datos de tal modo que no sea pre- 
ciso duplicar las funciones de gestión de datos en todas 
las herramientas CASE. 


), ¿Cuales son las características 
típicas de los SGBD que dan 
soporte a CASE ? 


Independencia de datos. Las herramientas CASE y 
las aplicaciones destino se aíslan del almacenamiento 
físico para que no se vean afectadas cuando la configu- 
ración del hardware se cambie. 


Control de transacciones. El repositorio implementa 
bloqueo de registros, admisiones de dos fases, registros 
de transacciones y procedimientos de recuperación para 
mantener la integridad de los datos cuando existen usua- 
rios concurrentes. 
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Información de la empresa 
Estructura organizativa 
Análisis del área de negocios 
Funciones de negocios 
Reglas de negocios 
Modelos de procesos (escenarios) 
Arquitectura de la información 


Diseño de aplicaciones 
Reglas de metodología 
Representaciones gráficas 
Diagramas de sistema 
Estándares de denominación 
Reglas de integridad referenciales 
Estructuras de datos 
Definiciones de proceso 
Definiciones de clase 
Arboles de menú 
Criterios de rendimiento 
Restricciones temporales 
Definiciones de pantalla 
Definiciones de informes 
Definiciones lógicas 
Lógicas de comportamiento 
Algoritmos 
Reglas de transformación 


TABLA 31.1. Contenido de un repositorio CASE [FOR89B]. 


Seguridad. El repositorio proporciona mecanismos 
para controlar quién puede visualizar y modificar la 
información contenida en él. 


Consultas e informes de datos ad hoc. El reposito- 
rio permite acceder directamente a su contenido 
mediante una interfaz de usuario cómoda tal como SQL, 
o mediante un «navegador» (browser)orientado a for- 
mularios, haciendo posible un análisis definido por el 
usuario que va más allá de los informes estándar pro- 
porcionados por el conjunto de herramientas CASE. 


Apertura. Los repositorios suelen proporcionar un 
mecanismo de importación/exportación sencillo que 
hace posible las cargas o transferencias de información 
al por mayor. 


Soporte multiusuario. Un repositorio robusto deberá 
permitir que múltiples desarrolladores trabajen en una 
aplicación al mismo tiempo. Deberá gestionar el acceso 
concurrente a la base de datos mediante múltiples 
herramientas y por parte de múltiples usuarios, con 
arbitraje de accesos y con bloqueos en el nivel de archi- 
vos Oregistros. Para los entornos basados en redes, el 
soporte multiusuario implica también que el reposito- 
rio se podrá comunicar mediante interfaz con proto- 
colos (agentes de solicitud de objetos) y servicios 
comunes de red. 

El entorno CASE también efectúa demandas espe- 
ciales con respecto al repositorio que van más allá de 
lo que está disponible directamenteen un SGBD comer- 
cial. Entre las características especiales de los reposi- 
torios CASE se incluyen las siguientes: 
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Construcción 
Código fuente; código objeto 
Instrucciones de construcción del sistema 
Imágenes binarias 
Dependencias de configuración 
Información de cambios 


Validación y verificación 
Plan de comprobación; casos de prueba de los 
datos 
Guiones de comprobación de regresión 
Resultados de comprobaciones 
Análisis estadísticos 
Métricas de calidad de software 


Información de gestión del proyecto 
Planes de proyecto 
Estructura de desglose de tareas 
Estimaciones; planificaciones 
Carga de recursos; informe de problemas 
Solicitudes de cambios; informes de estado 
Información de auditoría 


Documentación del sistema 
Documentos de requisitos 
Diseños internos/externos 
Manuales de usuario 


Almacenamiento de estructuras de datos sofistica- 
das. El repositorio debe admitir tipos de datos comple- 
jos tales como diagramas, documentos y archivos, así 
como sencillos elementos de datos. Un repositorio tam- 
bién incluye un modelo de información (o metamodelo) 
que describe la estructura, relaciones y semántica de los 
datos almacenados en él. El metamodelo deberá poder 
ampliarse para dar cabida a representaciones nuevas y 
a una información organizativa únicas. El repositorio 
no solamente almacena modelos y descripciones de los 
sistemas en desarrollo, sino que los metamodelos aso- 
ciados (esto es, una información adicional que describe 
la información de ingeniería del software en sí, tal como 
el momento en que se ha creado un componente de 
diseño concreto, su estado actual y la lista de compo- 
nentes de los cuales depende). 


¿Cuáles son las características 
especiales mostradas en el 
repositorio CASE? 


Imposición de una integridad. El modelo de infor- 
mación del repositorio contiene también reglas, o polí- 
ticas, que describen reglas de negocios válidas y otras 
restricciones y requisitos acerca de la información que 
se inserta en el repositorio (directamente o a través de 
una herramienta CASE). Es posible emplear un servi- 
cio llamado disparador para activar las reglas asocia- 
das a un objeto siempre que este sea modificado, lo cual 
hace posible verificar la validez de los modelos de diseño 
en tiempo real. 


www.elsolucionario.net 


INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRACTICO 


Referencia Web 


Un manual de aprendizajedetallado y una lista de 
recursos para repositorios OO (que se pueden utilizar para 
entoros CASE) se pueden encontrar en le dirección 
mini.net/cetus/oo_db_systems_T.html 


Interfaz de herramientas ricas en términos semánti- 
cos. El modelo de información del repositorio (el meta- 
modelo) contiene una semántica que hace posible que 
toda una gama de herramientas interpreten el signifi- 
cado de los datos almacenados en el repositorio. Por 
ejemplo, un diagrama de flujo de datos creado mediante 
una herramienta CASE se almacena en el repositorio en 
un formulario basado en el modelo de información e 
independiente de toda representación interna que pueda 
utilizar la herramientas en sí. Entonces otra herramienta 
CASE puede interpretar el contenido del repositorio y 
utilizar la información cuando la necesite para su tarea. 
De este modo, la semántica almacenada en un reposi- 
torio permite compartir datos entre una gran variedad 
de herramientas, a diferencia de las conversiones espe- 
cíficas entre herramientas, o entre «puentes». 


Gestión de procesosiproyectos. Un repositorio con- 
tiene información no sólo acerca de la aplicación de 
software en sí, sino también acerca de las característi- 
cas de cada proyecto en particular, y del proceso gene- 
ral de la organización para el desarrollo del software 
(fases, tareas y productos). Esto abre posibilidades para 
la coordinación automatizada de la actividad de desa- 
rrollo técnico con la actividad de gestión del proyecto. 
Por ejemplo, la actualización del estado de las tareas de 
proyectos se podría efectuar de forma automática o bien 
como un producto derivado de la utilización de herra- 
mientas CASE. La actualización de estadoresultará muy 
fácil para los desarrolladores, sin tener que abandonar 
el entorno de desarrollo normal. La asignación de tareas 
y consultas también se puede gestionar por correo elec- 
trónico. Los informes de problemas, las tareas de man- 
tenimiento, las autorizaciones de cambios, y los estados 
de reparación se pueden coordinar y monitorizar 
mediante herramientas que acceden al repositorio. 

Las siguientes características del repositorio son abar- 
cadas todas ellas por la gestión de configuración del soft- 
ware (Capítulo9). Se vuelven a examinar aquí para hacer 
hincapié en su interrelación con los entornos 1-CASE. 


Versiones.A medida que avanza un proyecto, se irán 
creando muchas versiones de productos individuales. 
El repositorio deberá ser capaz de guardar todas estas 
versiones para hacer posible una gestión efectiva de las 
versiones de los productos y para permitir que los desa- 
rrolladores vuelvan a las versiones anteriores durante 
la comprobación y depuración. 

4 ¿De qué forma presta ayuda 
el repositorioa la GCS? 
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El repositorio CASE deberá ser capaz de controlar 
una amplia variedad de tipos de objetos entre los que se 
incluyen texto, gráficos, mapas de bits, documentos 
complejos y objetos Únicos como definiciones de pan- 
talla y de informes, archivos de objetos, datos de com- 
probación y resultados. Un repositorio maduro rastrea 
las versiones de objetos con niveles arbitrarios de gra- 
nularidad, por ejemplo, se puede rastrear cada defini- 
ción de datos o agrupamiento de módulos. 


Para dar apoyo al desarrollo paralelo, el mecanismo 
de control de versiones deberá permitir múltiples deri- 
vados (variantes) a partir de un solo predecesor. Así pues, 
un desanollador podrá estar trabajando al mismo tiempo, 
en dos soluciones posibles para un problema de diseño 
generadas las dos desde el punto de partida. 


Seguimiento de dependencias y gestión de cambios. 
El repositorio gestiona una amplia variedad de relacio- 
nes entre los elementos de datos almacenados en él. 
Entre estas se cuentan las relaciones entre entidades y 
procesos de la empresa, entre las partes de un diseño de 
aplicación, entre componentes del diseño y la arquitec- 
tura de la información de la empresa, entre elementos 
de diseño y productos, etc. Algunas de las relaciones 
son meramente asociaciones, y algunas son dependen- 
cias Orelaciones obligatorias. El mantenimiento de estas 
relaciones entre objetos de desarrollo se denomina admi- 
nistración de enlaces. 


» 
Ss 


CLAVE 


La capacidaddel repositoriopara hacer seguimiento 

de los relacionesentre objetos de la configuración 

es una de Es característicosmás importantes. Elimpacto 
del cambio se puede rastrear si se dispone 

de esto característica. 


La capacidad de seguirla pista de todas estas relacio- 
nes es crucial para la integridad de la información alma- 
cenada en el repositorio y para la generación de productos 
basados en ella, y es una de las contribuciones más impor- 
tantes que efectúa el concepto de repositorio para la mejo- 
ra del proceso de desarrollo del software. Entre las muchas 
funciones que apoya la gestión de enlaces se cuenta la 
capacidad de identificar y estimar los efectos del cambio. 
A medida que los diseños evolucionan para satisfacer 
nuevos requisitos, la capacidad de identificartodos los 
objetos que podrían verse afectados hace posible una esti- 
mación más precisa del coste, del tiempo no operativo, 
y del grado de dificultad. También se ayuda a evitarefec- 
tos colaterales que en caso contrario darían lugar a defec- 
tos y a fallos del sistema. 

La gestión de enlaces ayuda al mecanismo de repo- 
sitorio para asegurar que la información del diseño sea 
correcta manteniendo sincronizadas las partes de un 
diseño. 

Por ejemplo, si se modifica un diagrama de flujo de 
datos, el repositorio puede detectar si los diccionarios 
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de datos relacionados, definiciones de pantallas y módu- 
los de códigos también requieren modificación y pue- 
dan llamar la atención del desarrollador los componentes 
afectados. 


Seguimiento de requisitos. Esta función especial 
depende de la gestión de enlaces y proporciona la capa- 
cidad de hacer seguimiento de los componentes de 
diseño y de los productos derivados que proceden de 
una especificaciónde requisitos específica (seguimiento 
progresivo). Además, proporciona la capacidad de iden- 
tificar cuáles son los requisitos que generaron cualquier 
producto derivado (seguimiento regresivo). 

Gestión de configuración. Una función de gestión de 
configuración que trabaja muy cerca de las funciones 
de versiones y gestión de enlaces para hacer seguimiento 


E ASISTIDA POR COMPUTADORA 


de una serie de configuraciones que representarán hitos 
específicos del proyecto o de versiones de producción. 
La gestión de versiones proporcionalas versiones nece- 
sarias, y la gestión de enlaces hace seguimiento de las 
interdependencias. 


Seguimientode auditoría. El seguimientode auditoría 
establece información extra acerca de cuándo, por qué, y 
por quién son efectuados los cambios. La información 
acerca de las fuentes de las modificaciones se pueden intro- 
ducir en forma de atributosde objetosespecíficos del repo- 
sitorio. Un mecanismodisparador del repositorioresultará 
útil para solicitar al desarrolladoro a la herramienta que 
esté utilizando que inicie la introducción de información 
de auditoría.(tal como la razón del cambio) siempre que 
se modifique un elemento de diseño. 


Las herramientas de ingeniería del software asistida por 
computadora abarcan todas las actividades del proceso 
del software y también aquellas actividades generales 
que se aplican a lo largo de todo el proceso. CASE com- 
bina un conjunto de bloques de construcción que 
comienzan en el nivel del hardware y del software de 
sistema operativo y finalizan en las herramientas indi- 
viduales. 

En este capítulo se ha tenido en consideración una 
taxonomía de herramientas CASE. Las categorías abar- 
can tanto las actividades de gestión como las técnicas, 
e incluyen la mayor parte de las áreas de aplicación del 
software. Todas las categorías de herramientas se han 
considerado «soluciones puntuales». 

El entorno 1-CASE combina mecanismos de inte- 
gración para datos, herramientas e interacción hombre- 
computadora. La integración de datos se puede conseguir 
mediante el intercambio directo de información, median- 
te estructuras de archivos comunes, mediante datos com- 
partidos o interoperabilidad, o a través de la utilización 
de un repositorio 1-CASEcompleto. La integración de 
herramientas se puede diseñar de forma personalizada 


por parte de fabricantes que trabajan a la vez, o bien se 
puede lograr mediante un software de gestión que se 
proporcione como parte del repositorio. 

La integración entre hombre y computadora se logra 
mediante estándares de interfaz que se están volviendo 
cada vez más comunes a lo largo y ancho de toda la 
industria. Para facilitar la integración de los usuarios 
con las herramientas, de las herramientas entre sí, de las 
herramientas con los datos y de los datos con otros datos 
se diseña una arquitectura de integración. 

Se ha aludido al repositorio CASE con el nombre de 
«bus de software». La información pasa por él, y va cir- 
culando de herramienta en herramienta a medida que 
progresa el proceso de software. Pero el repositorio es 
mucho más que un «bus», También se trata de un lugar 
de almacenamiento que combina sofisticados mecanis- 
mos para integrar herramientas CASE mejorando con- 
siguientementeel proceso mediante el cual se desarrolla 
el software. El repositorio es una base de datos relacio- 
nal u orientada a objetos que es «el centro de acumula- 
ción y almacenamiento»de la información de ingeniería 
del software. 


[FOR89a] Forte, G., «In Search of the Integrated Environ- 
ment», CASE Outlook, Marzo/Abril de 1989, pp. 5-12. 


[FOR89b] Forte, G., «Rally Round the Repository», CASE 
Outlook, Diciembre de 1989, pp. 5-27. 


[FOR90] Forte, G., «Integrated CASE: A Definition», Proc. 
3" Annual TEAMWORKERS Intl, User's Group Confe- 
rence, Cadre Technologies, Providence, IR, Marzo de 1990. 


[GRI195] Griffen, J., «Repositories: Data Dictionary Descen- 
dant Can Extend Legacy Code Investment», Application 
Development Trends, Abril de 1995, pp. 65-71. 


571 


[QED89] CASE: The Potential and the Pitfalls, QED Infor- 
mation Sciences, Inc., Wellsley, MA, 1989, 


[SHA95] Sharon, D., y R. Bell, «Tools that Bind: Creating 
Integrated Environments», JEEE Software, Marzo de 1995, 
pp. 76-85. 


[SQE95] Testing Tools Reference Guide, Software Quality 
Engineering, Jacksonville, FL, 1995. 


[WEL89] Welke, R.J. «Meta Systems on Meta Models», 
CASE Outlook, Diciembre de 1989,pp. 35-45. 
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31.1. Haga una lista de todas las herramientas de desarrollo 
de software que utilice. Organícelas de acuerdo con la taxo- 
nomía presentada en este capítulo. 


31.2. Empleando las ideas introducidas en los Capítulos 14 y 
16, ¿cómo cree usted que deberían de construirse los servicios 
de portabilidad? 


31.3. Construye un prototipo en papel para una herramienta 
de gestión de proyectos que abarque las categorías indicadas 
en la Sección 3 1.3.Utilice la Segunda Parte de este libro para 
obtener información adicional. 


31.4. Lleve a cabo una investigación acerca de los sistema de 
gestión de bases de datos orientados a objetos. Estudie por qué 
un SGBDOO sería ideal para herramientas GCS. 


31.5. Recoja la información de productos de al menos tres 
herramientas CASE en una categona especificada por su pro- 
fesor. Desarrolle una matriz que compare las características. 


31.6. ¿Existen situaciones en las cuales las herramientas de 
comprobación dinámicas sean «la Unica forma posible»? De 
ser así, ¿cuáles son? 


31.7. Describaotras actividades humanas en las cuales la inte- 
gración de un conjunto de herramientas haya proporcionado 
un mayor beneficio que la utilización de cada una de esas herra- 
mientas de forma individual. No utilice ejemplos de compu- 
tación. 

31.8. Describa lo que quiere decir la integración entre herra- 
mientas y datos con sus propias palabras. 


31.9. En diferentes lugares de este capítulo se utilizan los tér- 
minos metamodelos y metadatos. Describa lo que significan 
estos términos empleando sus propias palabras. 


31.10.¿Se le ocurre algún elemento de configuración adicio- 
nal que pudiera incluirse entre los elementos del repositorio 
mostrados en la Tabla 31.1? Haga una lista. 


En los años ochenta y principios de los noventa se publica- 
ron varios libros sobre CASE en un esfuerzo de sacar provecho 
del alto grado de interés de la industria en ese momento. Entre 
las primeras ofertas que todavía disfrutan de valor se encuentran: 


Bergin, T. et al., Computer-Aided Software Engineering: 
Issues and Trendsfor the 1990s and Beyond, Idea Group 
Publishing, 1993. 

Braithwaite, K.S., Application Development Using CASE 
Tools, Academic Press, 1990. 

Brown, A. W., D.J. Carney y E.J. Morris, Principles 0] 
CASE Tool Integration, Oxford University Press, 1994. 

Clegg,D., y R, Barker, CASE Method Fast-Track: ARAD 
Approach, Addison Wesley, 1994. 

Lewis, T.G., Computer-Aided Software Engineering, Van 
Nostrand-Reinhold, 1990. 

Mylls, R., Information Engineering; CASE Practices and 
Techniques, Wiley, 1993. 


En la antología de Chifofsky (Computer-Aided Software 
Engineering, IEEE Computer Society, 2.* Ed., 1992)se encuen- 
tra una colección útil de los primeros trabajos sobre CASE y 
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entornos de desarrollo de software. Muller y sus colaborado- 
res (ComputerAided Software Engineering, Kluwer Academic 
Publishers, 1996) han editado una colección de descripciones 
de investigación CASE a mediados de los noventa. La mejo- 
res fuentes de información actual sobre herramientas CASE se 
encuentran en Intemet, en publicaciones técnicas periódicas y 
en boletines informativos de industria. 

El estándar 1209IEEE (Evaluation and Selection of CASE 
Tools)presenta un conjunto de líneas generales para evaluar 
las herramientas CASE para los «procesos de gestión de pro- 
yectos, procesos de predesarrollo, procesos de desarrollo, pro- 
cesos de postdesarrollo y procesos integrales». Un informe 
detallado de Wallnau y Feiler (Tool Integration and Envi- 
ronment Architectures, Software Engineering Institutc, 
CMU/SEL-9 1-TR-11, Mayo de 1991), aunque esté fechado, 
sigue siendo uno de los mejores tratamientos sobre entornos 
CASE fácilmente disponibles. 

Una amplia variedad de fuentes de información sobre 
CASE está disponible en Intemet. Una amplia lista actuali- 
zada de referencias a sitios (páginas) web se puede obtener 
en http:/www.pressman5.com. 
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3 ») PERSPECTIVAS FUTURAS 


N los 3 1 capítulos anteriores, se ha ido explorando un proceso de ingeniería del softwa- 
re. Se han presentado procedimientos de gestión y métodos técnicos, principios básicos 
y técnicas especializadas, actividades orientadas a personas y tareas adecuadas para su 
automatización, notación de papel y lápiz y herramientas CASE. Se ha afirmado que la medi- 
da, la disciplina y un especial interés por la calidad darán lugar a un software que va a satisfa- 
cer las necesidades del usuario, a un software fiable, a un software mantenible y a un software 
mejor. Y, sin embargo, nunca se ha prometido que la ingeniería del software fuera la panacea. 


A medida que vamos avanzando hacia el comienzo de un nuevo siglo, la tecnología de soft- 
ware y de sistemas siguen siendo un desafío para todo profesional del software y para toda com- 
pañía que construya sistemas basados en computadoras. Aunque esto se escribió hace más de 
una década, Max Hopper [HOP90] describe el estado actual de los acontecimientos: 


Dado que los cambios de la tecnología de la información cada vez se producen más rápidamente y-son 
implacables, y dado que las consecuencias de quedarse atrás son irreversibles, las compañías tienen que 
dominar esta tecnología o morir. Hay que pensar que se trata del molino de la tecnología. Las compañías 
tendrán que correr cada vez más deprisa para estar a la altura. 


Los cambios de la tecnología de la ingeniería del software son, en efecto, «rápidos e impla- 
cables», pero al mismo tiempo el progreso suele ser bastante lento. Pero una vez que se toma 
la decisión de adaptar un método nuevo (o una herramienta nueva), la decisión de llevar a cabo 
la formación necesaria para comprender su aplicación, y la decisión de introducir la tecnología 
en la cultura de desarrollo del software, ya ha surgido algo nuevo (e incluso mejor) y comien- 
za de nuevo el proceso. 


VISTAZO RÁPIDO 


¿Qué es? El futuro nunca es fácil de pre- ¿por qué las grandes empresas multi- ¿Cuél es el producto obtenido? 


decir: los entendidos y expertos de la 
industria no seresisten. El futuro esta- 
ba plagado de carcasas de tecnologí- 
as nuevas y excitantes que realmente 
nunca llegaron a ser eso (apesar del 
bombo que tuvieron), y que adquirie- 
ron forma con tecnologías más moder- 
nas que de alguna manera modificaron 
su dirección y extensión. Por lo tanto 
no pretendemos predecir el futuro sino 
que estudiaremos algunos temas que 
hay que tener en cuenta para entender 
los cambios futurosde la ingeniería del 
software y del mismo software. 


¿Quién lo hace? Todos. 
¿Por qué es importante? ¿Por qué los 


reyes antiguos contrataban adivinos?, 


nacionales contratan a otras empresas 
asesoras y a grandes pensadores paru 
preparar los pronósticos?, ¿por qué un 
gran porcentaje de lectores están pen- 
dientes de los horóscopos? Queremos 
saber lo que va a ocurrir para estar 
preparados. 


¿Cuáles son los pasos? No hay una 


fórmula para predecir el futuro. Lo 
hemos intentado recogiendo datos y 
organizándolos con el fin de propor- 
cionar una información útil; exami- 
nando las asociaciones sutiles para 
extraer el conocimiento y, a partir de 
éste, sugerir posibles apariciones 
que predecirán cómo será todo en el 
futuro. 


Una visión del término futuro que 
pueda o no ser correcta. 


¿Cómo puedo estar seguro de que 


lo he hecho correctamente? 
Predecir el futuro es un arte, no una 
ciencia. De hecho, es bastante extra- 
ño cuando se ha hecho una predic- 
ción seria, que ésta sea absolu- 
tamente verdadera O inequívoca- 
mente errónea (con la excepción, 
afortunadamente,de las prediccio- 
nes sobre el fin del mundo). Se bus- 
can tendencias y se intenta extra- 
polarlas al futuro. Solamente se pue- 
de evaluar la corrección de esta 
extrapolación a medida que pasa el 
tiempo. 


En este capítulo se examinan las tendencias futuras. Nuestro intento no es explorar todas las 
áreas de investigación que resulten prometedoras. Tampoco lo es mirar en una «bola de cris- 
tal» y pronosticar el futuro, más bien se intentará explorar el ámbito del cambio y la forma en 
que el cambio en sí va a afectar al proceso del software en los años venideros. 
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La importancia del software de computadora se puede 
enunciar de muchas formas. En el Capítulo 1,el soft- 
ware se caracterizaba como diferenciador. La función 
proporcionada por el software es lo que diferencia a los 
productos, sistemas y servicios, y proporciona una ven- 
taja competitiva en el mercado. Sin embargo, el soft- 
ware es más que un diferenciador. Los programas, 
documentos y datos que constituyen el software ayu- 
dan a generar la mercancía más importante que pueda 
adquirir cualquier individuo, negocio o gobierno —la 
información —. Pressman y Herron [PRE91] describen 
el software de la forma siguiente: 


El software de computadora es una de las pocas tecnologí- 
as clave que tendrán un impacto significativoen los años 90. 
Se trata de un mecanismo para automatizar negocios, indus- 
trias y gobiernos, un medio para transferir nuevas tecnologías, 
un método para adquirir experiencia valiosa que otras perso- 
nas puedan utilizar, un medio para diferenciarlos productos de 
una compañía de los productos de los de sus competidores, y 
una ventana que permite examinar el conocimiento colectivo 


de una corporación. El software es crucial para casi todos los 
aspectos del negocio. Pero de muchas maneras, el software es 
también una tecnología oculta. Encontramos el software (fre- 
cuentemente, sin darnos cuenta) cuando nos desplazamos has- 
tanuestro trabajo, cuandoefectuamos cualquier compra, cuando 
nos detenemos en el banco, cuando hacemos una llamada tele- 
fónica, cuando visitamos al médico o cuando realizamos cual- 
quiera de los cientos de actividades diarias que reflejan la vida 
moderna. 


El software está en todas partes y, sin embargo, hay muchas 
personas en puestos de responsabilidadque tienen poca o nin- 
guna comprensión de lo que realmente es, como se construye, 
o de loque significapara las institucionesque lo controlan (y a 
las que controla). Y, lo quees más importante, tienen muy poca 
idea de los peligros y oportunidadesque este software ofrece. 

La omnipresencia del software nos lleva a una con- 
clusión sencilla: siempre que una tecnología tiene un 
impacto amplio —un impacto que puede salvar vidas o 
ponerlas en peligro, construir negocios o destruirlos, 
informar a los jefes de gobierno o confundirlos —, es 
preciso «manejarla con cuidado». 


Los cambios en la informática durante los últimos 50 


años han sido controlados por los avances en las «cien- 
cias experimentales duras» —físicagquímica, ciencia de 
materiales e ingeniería —. Durante las próximas déca- 
das, los avancesrevolucionariosen la informática serán 
dirigidos por las ciencias no experimentales suaves» 
—.ppsicologíahumana, biología, neurofisiología, socio- 
logía, filosofía y otras —. El período de gestación de las 
tecnologías informáticas que se puede derivar de estas 
disciplinas es muy difícil de predecir. 


es que cada vez llego un día nuevo. 


Es posible que la influencia de las ciencias no expe- 
rimentales ayude a moldear la dirección de la investi- 
gación informática en las ciencias experimentales. Por 
ejemplo, el diseño del las «computadoras futuras» pue- 
de que sea dirigido más por un entendimiento de la psi- 
cología del cerebro que por el entendimiento de la 
microelectrónica convencional. 

Los cambios que afectarán a la ingeniería del soft- 
ware durante la próxima década se verán influenciados 
por cuatro fuentes simultáneas: (1) las personas que rea- 
lizan el trabajo; (2) el proceso que aplican; (3) la natu- 
raleza de la información, y (4) la tecnología informática 
subyacente. En las secciones siguientes, cada uno de 
estos componentes — personas,proceso, información y 
tecnología — se estudiarán detalladamente. 


El software necesario para los sistemas de alta tecnología 
cada vez son más difíciles a medida que van pasando los 
años y el tamaño de los programas resultantes incremen- 
ta de manera proporcional. El crecimientorápido del tama- 
ño del programa «promedio»nos presentará unos cuantos 
problemas si no fuera por el simple hecho de que: a medi- 
da que el programa aumenta, el número de personas que 
deben trabajar en él también aumenta. 

La experiencia indica que a medida que aumenta el 
número de personas de un equipo de proyecto de soft- 
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ware, es posible que la productividad global del grupo 
sufra. Un método para resolver este problema es crear 
un número de equipos de ingeniería del software, por 
el que se compartimentalicen las personas en grupos de 
trabajo individuales. Sin embargo, a medida que el 
número de equipos de ingeniería del software aumen- 
ta, la comunicación entre ellos es tan difícil y largacomo 
la comunicación entre individuos. Es aún peor, la comu- 
nicación (entre individuos o equipos) —es decir, es 
demasiado tiempoel que se pasa transfiriendo poco con- 
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tenido de información, y toda esta información impor- 
tante suele «perderse entre las grietas»—, 

Si la comunidad de ingeniería del software va a tra- 
tar el dilema de la comunicación de manera eficaz, el 
futuro de los ingenieros deberá experimentar cambios 
radicales en la forma en que los individuos y los equi- 
pos se comunican entre sí. El correo electrónico, los 
tablones de anuncios y los sistemas de videoconferen- 
cia son los lugares comunes como mecanismos de cone- 
xión entre muchas personas de una red de información. 
La importancia de estas herramientas en el contexto del 
trabajo de la ingeniería del software no se puede sobre- 
valorar. Con un sistema de correo electrónico o de tablón 
de anuncios eficaz, el problema que se encuentra un 
ingeniero del software en la ciudad de Nueva York, se 
puede resolver con la ayuda de un compañero en Tokio. 
En realidad, los tablones de anuncios y los grupos de 
noticias especializados se convierten en los depósitos 
de conocimiento que permiten recoger un conocimien- 
to colectivo de un grupo grande de técnicos para resol- 
ver un problema técnico o un asunto de gestión. 


vro es el tremendo agobio 
bn que inducimos en los individuos 
siados cambios en períodos 


El vídeo personaliza la comunicación. Y lo mejor es 
que hace posible que compañeros en lugares diferentes 
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(o en continentes diferentes) se «encuentren» regular- 
mente. Pero el vídeo también proporciona otra ventaja: 
se puede utilizar como depósitopara conocimiento sobre 
el software y para los recién llegados a un proyecto. 


La evolución de los agentes inteligentes también 
cambiará los patrones de trabajo de un ingeniero del 
software ampliando dramáticamente las herramientas 
del software. Los agentes inteligentesmejorarán la habi- 
lidad de los ingenieros mediante la comprobación de 
los productos del trabajo utilizando el conocimiento 
específico del dominio, realizando tareas administrati- 
vas, llevando a cabo una investigación dirigida y coor- 
dinando la comunicación entre personas. 

Finalmente, la adquisiciónde conocimientoestá cam- 
biando profundamente. En Intemet, un ingeniero del soft- 
ware puede subscribirse a un grupo de noticias centrado 
en áreas de tecnología de inmediata preocupación. Una 
pregunta enviada a un grupo de noticias provoca res- 
puestas de otras partes interesadas desde cualquier lugar 
del globo. La World Wide Web proporciona al ingenie- 
ro del software la biblioteca más grande del mundo de 
trabajos e informes de investigación, manuales, comen- 
tarios y referencias de la ingeniería del software". 

Si la historia pasada se puede considerar un indicio, 
es justo decir que las mismas personas no van a cam- 
biar. Sin embargo, las formas en que se comunican, el 
entorno en el que trabajan, la forma en que adquieren 
el conocimiento, los métodos y herramientas que utili- 
zan, la disciplina que aplican, y por tanto, la cultura 
general del desarrollo del software sí cambiarán signi- 
ficativa y profundamente. 


Es razonable caracterizar las dos primeras décadas de 
la práctica de ingeniería del software como la era del 
«pensamientolineal», Impulsado por el modelo de ciclo 
vital clásico, la ingeniería del software se ha enfocado 
como una actividad en la cual se podían aplicar una serie 
de pasos secuenciales en un esfuerzo por resolver pro- 
blemas complejos. Sin embargo, los enfoques lineales 
del desarrollo del software van en contra de la forma en 
que se construyen realmente la mayoría de los sistemas. 
En realidad, los sistemas complejos evolucionan de for- 
ma iterativa, e incluso incremental. Por esta razón, un 
gran segmento de la comunidad de la ingeniería del soft- 
ware se está desplazando hacia modelos evolutivos para 
el desarrollo del software. 

Los modelos de proceso evolutivos reconocen que la 
incertidumbre domina la mayoría de los proyectos; que las 
líneas temporales suelen ser imposibles y cortas; y que la 
iteración proporciona la habilidad de dar una soluciónpar- 
cial, aunque un producto completo no es posible dentro 
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del marco de tiempo asignado. Los modelos evolutivos 
hacen hincapié en la necesidad de productos de trabajo 
incrementales, análisisde riesgos, planificacióny revisión 
de planes, y realimentación que provenga del cliente. 


trabajo para mañana 


¿Qué actividades deberán de poblar el proceso evo- 
lutivo? A lo largo de la década pasada, el Modelo de 
madurez de capacidad desarrollado por el Software 
Engineering Institute (SEI) [PAU93] ha tenido un impac- 
to apreciable sobre los esfuerzos por mejorar las prác- 
ticas de ingeniería del software. El MMC ha dado lugar 
a muchos debates (por ejemplo, [BOL91] y [GIL96]), 
y sinembargo proporciona una buena indicación de los 


"El sitio Web SEPA puede proporcionar enlaces electrónicos con las 
materias más importantes que se presentan en este libro. 
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atributos que deben existir cuando se pone en práctica 
una buena ingeniería del software. 

Las tecnologías de objetos, junto con la ingeniería del 
software (Capítulo 27) son un brote de la tendencia hacia 
los modelos de proceso evolutivos. Ambos tendrán un 
impacto profundo sobre la productividad de desarrollo del 
software y sobre la calidad del producto. La reutilización 
de componentes proporciona beneficiosinmediatosy con- 
vincentes. Cuando la reutilización se une a las herramientas 
CASE para los prototipos de una aplicación, los incre- 
mentos del programa se pueden construirmucho más rápi- 
damente que mediante la utilización de enfoques 
convencionales. La construcción de prototipos arrastran 
al cliente al proceso. Por tanto es probable que clientes y 
usuarios se impliquen más en el desarrollo del software. 
Esto, a su vez, puede llevar a una satisfacción mayor del 
usuario final y a una calidad mejor del software global. 


El crecimientorápido de las aplicaciones basadas en 
Web (WebApps) está cambiando tanto en el proceso de 
la ingeniería del software como en sus participantes. De 
nuevo, nos encontramos con un paradigma incremen- 
tal y evolutivo. Pero en el caso de las WebApps, la inme- 
diatez, seguridad y estética se están convirtiendo en las 
preocupaciones dominantes. Un equipo de ingeniería 
de Web mezcla técnicos con especialistas de contenido 
(por ejemplo, artistas, músicos, videógrafos) para cons- 
truir una fuente de información para una comunidad de 
usuarios grande e impredecible. El software que ha sur- 
gido del trabajo de la ingeniería de Web ya ha dado como 
resultado un cambio radical tanto económico como cul- 
tural. Aunque los conceptos y principios básicos trata- 
dos en este libro son invariables,el proceso de ingeniería 
del software deberá adaptarse para llegar a acoplarse a 
la Web. 


A lo largo de las dos últimas décadas, se ha producido 
una sutil transición en la terminología que se utiliza para 
describir el trabajo de desarrollo de software realizado 
para la comunidad de negocios. Hace treinta años, el 
término procesamiento de datos era la frase operativa 
para describirla utilización de computadoras en un con- 
texto de negocio. En la actualidad, el proceso de datos 
ha dado lugar a otra frase —tecnologíade la informa- 
ción — que significa lo mismo pero presenta un sutil 
cambio de nuestro centro de atención. La importancia 
ya no está meramente en procesar grandes cantidades 
de datos, sino más bien en extraer una información sig- 
nificativa a partir de estos datos. Evidentemente, éste 
ha sido siempre el objetivo, pero el cambio de la ter- 
minología refleja un cambio bastante más importante 
en la filosofía de la gestión. 

Cuando en la actualidad se describen las aplicacio- 
nes de software, las palabras datos e información apa- 
recen en numerosas ocasiones. La palabra conocimiento 
se encuentraen algunas aplicaciones de inteligencia arti- 
ficial, pero su utilización es relativamente escasa. Casi 
nadie describe la sabiduría en el contexto de las aplica- 
ciones del software para computadoras. 

Los datos son información pura —una colección de 
hechos que es preciso procesar para que sean significa- 
tivos—. La información se deriva asociando los hechos 
en el seno de un contexto dado. El conocimiento aso- 
cia la información obtenida en un contexto con otra 
información obtenida en un contexto distinto. Por Últi- 
mo, la sabiduría se produce cuando se derivan unos prin- 
cipios generalizados de conocimientos dispares. Estos 
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. 
datos: 
No hay asociatividad 


Información: 
Asociatividad en un 
solo contexto 


Sabiduría: 

Creación de principios 
generalizados basándose 

en el conocimiento 

procedente de distintas fuentes 


Conocimiento: 
Asociatividad 
entre contextos 
múltiples 


FIGURA 32.1. Un espectro de «información». 


cuatro puntos de vista de la «información» se han repre- 
sentado esquemáticamente en la Figura 32.1. 

Hasta la fecha, la gran mayoría del software que se 
ha construido ha tenido como misión procesar datos o 
información. Los ingenieros de software del siglo vein- 
tiuno seguirán estando Preocupados por sistemas que 
procesen conocimiento”. El conocimiento es bidimen- 
sional. La información recogida acerca de una gama 
amplia de temas relacionados y no relacionados se agru- 
pan para formar un cuerpo de hechos al que se deno- 
mina conocimiento. La clave es nuestra capacidad para 
asociar información de una gama de fuentes distintas 
que puedan no poseer conexiones evidentes entre sí y 


? El crecimiento rápido de las tecnologías de minería de datos (data 
mining) y de almacenes de datos (data warehousing) reflejan este 
rápido crecimiento. 
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combinarlas de modo que nos proporcione algún bene- 
ficio definido. 


poder que nos copacito para 
fo en nuestro propio beneficio 


Para ilustrar la progresión desde los datos al cono- 
cimiento, consideraremos los datos del censo que indi- 
can que el número de nacimientos en los Estados 
Unidos en 1996 fue de 4,9 millones. Este número 
representa un valor de datos. Al relacionar este dato 
con los nacimientos de los cuarenta años anteriores se 
puede extraer un elemento de información útil: aque- 
llas personas que tuvieron muchos hijos en los años 
50 y a principios de los 60, están efectuando un últi- 
mo esfuerzo por tener niños antes de llegar al final de 
sus años fértiles. Esta información se puede conectar 
entonces con otros elementos de información aparen- 
temente no relacionados, por ejemplo, el número actual 
de profesores de escuelas primarias que se retirarán 
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durante la próxima década, el número de alumnos que 
cursarán estudios primarios y secundarios, O la pre- 
sión habida sobre los políticos para reducir los impues- 
tos y limitar por tanto los aumentos de sueldo para los 
profesores. 

Todos estos elementos de información se pueden 
combinar para formular una representación del conoci- 
miento -existiráuna presión significativa sobre el sis- 
tema de educación de los Estados Unidos a principios 
del siglo veintiuno y esta presión proseguirá durante 
más de una década—. Mediante este conocimiento, pue- 
de aparecer la oportunidad de un negocio. Quizá exis- 
tan oportunidadessignificativaspara desarrollar nuevos 
modelos de aprendizajeque sean más efectivas y menos 
costosas que los enfoques actuales. 

El futuro del software conduce a sistemas que pro- 
cesan el conocimiento. Se ha estado procesando datos 
durante cincuenta años y extrayendo información duran- 
te casi tres décadas. Uno de los desafíos más significa- 
tivos a los que se enfrenta la comunidad de la ingeniería 
del software consiste en construir sistemas que den el 
siguiente paso en el espectro: sistemas que extraigan el 
conocimiento de los datos y de la información para que 
sea práctica y beneficiosa. 


Las personas que construyen y utilizan software, el pro- 
ceso de ingeniería del software que se aplica, y la infor- 
mación que se produce se ven afectados todos ellos por 
los avances en la tecnología del hardware y software. 
Históricamente, el hardware ha servido como impulsor 
de la tecnología de la computación. Una nueva tecno- 
logía de hardware proporciona un potencial. Entonces 
los constructores de software reaccionan frente a las 
solicitudes de los clientes en un intento de aprovechar 
ese potencial. 

Las tendencias futuras de la tecnología del hardware 
tienen probabilidades de progresar en dos rutas parale- 
las. En una de las rutas, las tecnologías de hardware 
seguirán evolucionando rápidamente. Mediante la mayor 
capacidad que proporcionan las tecnologías de hard- 
ware tradicionales, las demandas efectuadas a los inge- 
nieros de software seguirán creciendo. 


independencia electrónica recrea al mundo 
semejanza del pueblo global. 


Pero los cambios verdaderos de la tecnología de 
hardware se pueden producir en otra dirección. El 
desarrollo de arquitecturas de hardware no tradicio- 
nales (por ejemplo, máquinas masivamente paralelas, 
procesadores Ópticos y máquinas de redes neurona- 
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les) pueden dar lugar a cambios radicales en la clase 
de software que se puede construir y también a cam- 
bios fundamentales en nuestro enfoque de la ingenie- 
ría del software. Dado que estos enfoques no tradicio- 
nales siguen estando en el primer segmento del ciclo 
de quince años, resulta difícil predecir la forma en que 
el mundo del software se modificará para adaptarse a 
ellas. 

Las tendencias futuras de la ingeniería del softwa- 
re se verán impulsadas por las tecnologías de softwa- 
re. La reutilización y la ingeniería del software basada 
en componentes (tecnologías que todavía no están 
maduras) ofrecen la mejor oportunidad en cuanto a 
mejoras de gran magnitud en la calidad de los siste- 
mas y se encuentran en el momento de comerciali- 
zarse. De hecho, a medida que pasa el tiempo, el 
negocio del software puede empezar a tener un aspec- 
to muy parecido al que tiene el negocio del hardwa- 
re en la actualidad. Quizá existan fabricantes que 
construyan dispositivos diferentes (componentes de 
software reutilizables), otros fabricantes que cons- 
truyan componentes de sistemas (por ejemplo, un con- 
junto de herramientas para la interacción hombre- 
máquina) e integradores de sistemas que proporcio- 
nen soluciones para el usuario final. 

La ingeniería del software va a cambiar —de eso 
podemos estar seguros —. Pero independientemente de 
lo radicales que sean los cambios, podemos estar segu- 
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ros de que la calidad nunca perderá su importancia, y 
de que un análisis y diseño efectivosjunto con una com- 


probación competente siempre tendrán su lugar en el 
desarrollo de sistemas basados en computadoras. 


Ya han pasado 20 años desde que se escribió la prime- 
ra edición de este libro. Y todavía me acuerdo de cuan- 
do era un joven profesor sentado en mi mesa y 
escribiendo (a mano) el manuscrito de un libro sobre un 
tema que no preocupaba a muchas personas y que aún 
menos entendían realmente. Recuerdo la cartas de los 
editores rechazando el libro y argumentando (de forma 
educada, pero contundente) que nunca habría mercado 
para un libro sobre «ingeniería del software». Afortu- 
nadamente, McGraw-Hill decidió intentarlo”, y el res- 
to ya es historia. 

Durante los Últimos veinte años, este libro ha cam- 
biado espectacularmente - e námbito, tamaño, estilo y 
contenido —. Al igual que la ingeniería del software mis- 
ma, el libro también ha crecido, y por suerte también ha 
madurado durante los Últimos años. 

Hoy en día un enfoque de ingeniería en el desarro- 
llo del software de computadora es una sabiduría 
convencional. Aunque continúe el debate sobre el «para- 
digma adecuado», el grado de automatización y los 
métodos más efectivos, hoy en día los principios sub- 
yacentes de la ingeniería del software se aceptan a tra- 
vés de la industria. Entonces, ¿por qué solo hace muy 
poco tiempo que estamos siendo testigos de su gran 
adopción? 

La respuesta, creo yo, radica en la dificultad de la 
transición de la tecnología y el cambio cultural que la 
acompaña. Aunque la mayoría de nosotros apreciamos 
la necesidad de una disciplina de ingeniería para el soft- 
ware, luchamos contra la inercia de la práctica anterior 
y nos enfrentamos con nuevos dominios de aplicacio- 
nes (y los que diseñan que son quienes trabajan en ellos) 


los cuales parecen estar preparados a repetir los errores 
del pasado. 

Para facilitar la transición necesitamos muchas cosas 
—an proceso de software adaptable y sensible, métodos 
más eficaces, herramientas más potentes y una acepta- 
ción mejor de sus partidarios y soporte de los directores, 
y una dosis no pequeña de educación y «publicidad»—. 
La ingeniería del software no ha disfrutado de una gran 
publicidad, pero a medida que va pasando el tiempo el 
concepto se vende solo. De alguna manera, este libro es 
un «anuncio» para la tecnología. 

Es posible no estar de acuerdo con todos los enfo- 
ques descritos en este libro. Algunas de las técnicas y 
Opiniones son polémicas; otras deberán ajustarse para 
trabajar en diferentes entornos de desarrollo de softwa- 
re. Sin embargo, mi sincera esperanza es que [ngenie- 
ría del Software: Un enfoque práctico haya dibujado 
los problemas con los que nos enfrentamos; haya demos- 
trado las ventajas de los conceptos de la ingeniería del 
software, y haya proporcionado un marco de trabajo de 
métodos y herramientas. 

Como empieza un nuevo milenio, el software se 
ha convertido en el producto más importante de la 
industria y también más importante a nivel mundial. 
Su impacto e importancia han recorrido un largo cami- 
no. Y, sin embargo, una nueva generación de desa- 
rrolladores de software deberán encontrarse con 
muchos de los mismos retos con los que se enfrenta- 
ron generaciones anteriores. Esperemos que aquellas 
personas que se encuentren con el reto — ingenieros 
del software — tengan la sabiduría de desarrollar sis- 
temas que mejoren la condición humana. 


[BOL91] Bollinger, T., y C. McGowen, «A Critical Look at 
Software Capability Evaluations,» IEEE Software, Julio 
de 1991,pp. 25-41. 


[GIL96] Gilg, T., «What is level Six?», IEEE Software, Ene- 
ro de 1996, pp. 97-98 y 103 


3 Realmente los méritos son de Peter Freeman y Eric Munson, que 
fueron quienes convencieron a McGraw-Hill de que valdría la pena 
intentarlo. 
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[HOP90] Hopper, M.D., «Rattling SABRE, New Ways to 
Compete on Information», Harvard Business Review, 
Mayo-Junio de 1990. 

[PAU93] Paulk, M. et al., Capability Maturity Model for 


Software, Software Engineering Institute, Camegie Mellon 
University, Pittsburgh, PA, 1993, 


www.elsolucionario.net 


CAPÍTULO 32 PERSPECTIVAS FUTURAS 


32.1 Consiga una copia de las mejores revistas de negocios y 
de noticias de esta semana (por ejemplo: Newsweek, Time, Busi- 
ness Week). Haga una lista de todos los artículos o noticias que 
se puedan utilizar para ilustrar la importancia del software. 


32.2 Uno de los dominios de aplicaciones de software más 
candentes son los sistemas y las aplicaciones basados en Web 
(Capítulo 29). Estudie la forma en que las personas, comuni- 
cación y proceso tienen que evolucionar para adoptar el desa- 
rrollo de WebApps de «próxima generación». 


32.3 Escriba una breve descripción del entorno de desarrollo 
ideal de un ingeniero del software hacia el año 2010. Descri- 
ba los elementos del entorno (hardware, software y tecnolo- 
gías de comunicación) y su impacto en la calidad y el tiempo 
de comercialización. 


32.4 Revise el estudio de los modelos de proceso evolutivo 
del Capítulo 2. Haga una investigación y recoja artículos 
recientes sobre este tema. Resuma las ventajas e inconvenientes 
de los paradigmas evolutivos basados en las experiencias indi- 
cadas en los artículos. 


32.5 Intente desarrollar un ejemplo que comience con la 
recolección de datos puros y dé lugar a la adquisición de 
información, después del conocimiento, y finalmente de sabi- 
duría. 


32.6 Seleccione una tecnología de actualidad «candente» (no 
necesita ser una tecnología de software) que se esté estudian- 
do en los medios populares y describa la forma en que el soft- 
ware posibilita su evolución e impacto. 


Los libros que estudian las tendencias futuras del software 
y de la computación abarcan una amplia gama de temas téc- 
nicos científicos, económicos, políticos y sociales. Robertson 
(The New Renaissance: Computers and The Next Level of 
Civilization, Oxford University Press, 1998), argumenta que 
larevolución informática puede que sea el Único avance más 
significativo en la historia de la civilización. Dertrouzos y 
Gates (What Will Be: How The New World of Information 
Will Change OurLives, Harperbusiness, 1998)proporcionan 
un profundo estudio de algunas de las direcciones que las tec- 
nologías de la información pueden seguir en las primeras 
décadas de este siglo. Bamatt (Valueware: Technology, Huma- 
nity and Organization, Praeger Publishing, 1999)presenta un 
estudio intrigante de la «economía de las ideas» y de la for- 
ma en que se creará el valor económico a medida que evolu- 
ciona el ciber-negocio. El libro de Negroponte (Being Digital, 
Alfred A. Knopf, Inc., 1995) fue un best seller a mediados de 
los noventa y continúa proporcionando una visión interesan- 
te de la computación y de su impacto global. 

Kroker y Kroker (DigitalDelirium, New World Perspecti- 
ves, 1997) han publicado una colección polémica de ensayos, 
poemas y humor en donde examinan el impacto de las tecno- 
logías digitales en las personas y en la sociedad. Brin (TheTrans- 
parent Society: Will Technology Force us To Choose Between 
Privacy and Freedom?, Perseus Books, 1999) repasa el debate 
continuo asociado a la pérdida inevitable de privacidad perso- 
nal que acompaña al crecimiento de las tecnologías de la infor- 
mación. Shenk (DataSmog: Surviving the Information Glut, 
Harpercollins, 1998) estudia los problemas asociados con la 
«sociedad infectada de información» que se está produciendo 
del volumen de información que producen las tecnologías de 
información. 

Miller, Michalski y Stevens (21% Century Technologies: 
Promises and Perils of a Dynamic Future, Brookings Insti- 
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tution Press, 1999) han publicado una colección de artículos 
y ensayos sobre el impacto de la tecnología en las estructu- 
ras sociales, de negocios y económicas. Para aquellos que 
estén interesados en estos temas técnicos, Luryi, Xu y Zas- 
lavsky (Future Trends in Microelectronics, Wiley, 1999) han 
publicado una colección de artículos sobre las direcciones 
probables del hardware de computadora. Hayzelden y Big- 
ham (Software Agents for Future Communication Systems, 
Springer Verlag, 1999) han editado una colección que estu- 
dia las tendencias del desarrollo de los agentes de software 
inteligentes. 

Kurzweil (The Age of Spiritual Machines, When Compu- 
ters Exceed Human Intelligence, Viking/Penguin Books, 1999) 
argumenta que dentro de 20 años la tecnología del hardware 
tendrá la capacidad de modelar completamente el cerebro 
humano. Borgman (Holding on to Reality: The Nature of 
Information at the Turn of the Millenium, University of Chi- 
cago Press, 1999) ha escrito una historia de información intri- 
gante, haciendo un seguimiento de su papel en la 
transformación de la cultura. Devlin (InfoSense: Turning Infor- 
mation into Knowledge, W.H. Freeman  Co., 1999) trata de 
dar sentido al constante flujo de información que nos bom- 
bardea día a día. Gleik (Faster: TheAcceleration of Just About 
Everything, Pantheon Books, 2000) estudia el ritmo cada vez 
más veloz del cambio tecnológico y de su impacto en todos 
los aspectos de la vida moderna. Jonscher (The Evolution of 
WiredLife: From the Alphabet to the Soul-Catcher Chip-How 
Information Technologies Change Our World, Wiley, 2000) 
argumenta que el pensamiento humano y la interacción tras- 
cienden la importancia de la tecnología. 

Una variedad de fuentes de información sobre las ten- 
dencias futuras en la informática está disponible en Intemet. 
Una lista actualizada de referencias en la red se puede encon- 
traren http://www.pressman5.com 
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SIGLAS MÁS COMUNES EN 
INGENIERÍA DEL SOFTWARE 


Siglas Español / Inglés 
Término en Español 


AAN (Análisis del área del negocio) 

ACC (Autoridad de control de cambio) 

ACO (Acoplamiento entre clases de objetos) 

ACPs (Áreas clave de proceso) 

ACV (Arquitectura del ciclo de vida) 

ADOO (Análisis del dominio orientado a objetos) 
AE (Análisis estructurado) 

AG2D (Análisis geométrico de dos dimensiones) 
AG3D (Análisis geométrico de tres dimensiones) 
AOO (Análisis orientado a objetos) 

APD (Acceso público a datos miembros) 

APH (Árbol de profundidad de herencia) 

API (Interfaz de programación de aplicaciones) 
AROO (Análisis de los requisitos orientado a objetos) 
AVG (Análisis de valor ganado) 

AVL (Análisis de valores límites) 

BDK (Kit de desarrollo Bean) 

BRO (Operador relacional y de ramificación) 

BS (brutos.sueldos) 

C (Certificación) 

C (Consulta) 

CKX1I (construcción e integración) 

C/S (Cliente/servidor) 

CAD (Diseño asistido por computadora) 

Cadena DU (cadena de definición-uso) 

CASE (Ingeniería del software asistida por computadora) 
CC (Centralizado controlado) 

CCM (Carencia de cohesión en los métodos) 

CEU (Comprobación estadística de utilización) 
CFD (Cohesiones funcionales débiles) 

CFF (Cohesiones funcionales fuertes) 

CGI (Interfaz común de pasarela) 

CGO (Capa de gestión de objetos) 

CK serie de métricas (Chidamber y Kemerer) 

CN (Control numérico) 

CO (Complejidad de operación) 

COCOMO (Modelo constructivo del coste) 

COI (Capacidad operativa inicial) 

COM (Modelo de objetos para componentes) 
CORBA “Arquitectura común de distribución de objetos) 
CP (Control de periféricos) 

CPTP (Coste de presupuestos del trabajo planificado) 
CPTR (Coste de presupuestos del trabajo realizado) 
CR (Conveniencia de la representación) 

CRC (Clase-responsabilidad-colaboración) 

CRTR (Coste real de trabajo realizado) 

CTA (Control de tráfico aéreo) 

CYD (Comerciales ya desarrolladas) 

DBC (Desarrollo basado en componentes) 

DC (Descentralizado controlado) 

DCBC (Descubrimiento de conocimiento en bases de datos) 
DCS (Diagrama de contexto del sistema) 

DD (Descentralizado democrático) 

DDE (Desviación deliverada de la especificación) 
DER (Diagrama de entidad-relación) 

DF (Diseño formal) 
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BAA (Business Area Analysis) 

CCA (Change Control Authority) 

CBO (Coupling Between Object Classes) 
KPAs (Key Process Áreas) 

LCA (Life Cycle Architecture) 

OODA (Object-Oriented Domain Analysis) 
SA (Structured Analysis) 

2DGA (Two-dimensional Geometric Analysis) 
3DGA (Three-dimensional Geometric Analysis) 
OO0A (Object-Oriented Analysis) 

PAD (Public Access to Data members) 

DIT (Depth of the Inheritance Tree) 

API (Application Programming Interface) 
OORA (Object-Oriented Requirements Analysis) 
EVA (Earned Value Analysis) 

BVA (Boundary Value Analysis) 

BDK (Bean Development Kit) 

BRO (Branch and Relational operator) 

GW (gross.wages) 

C (Certification) 

Q Query) 

Cé€l (Construction and Integration) 

C/S (Client/server) 

CAD (Computer-Aided Design) 

DU chain (Definition-Use chain) 

CASE (Computer-Aided Software Engineering) 
CC (Controlled Centralised) 

LCOM (Lack of Cohesion in Methods) 

SUT (Statistical Use Testing) 

WFC (Weak Function Cohesion) 

SFC (Strong Functional Cohesion) 

CGI (Common Gateway Interface) 

OML (Object Management layer) 

CK metrics suite (Chidamber and Kemerer metrics) 
NC (Numerical Control) 

OC (Operation Complexity) 

COCOMO (Constructive Cost Model) 

IOC (Initial Operational Capability) 

COM (Component Object Model) 

CORBA (Common Object Request Broker Architecture) 
PC (Peripheral Control) 

BCWS (Budgeted Cost of Work Scheduled) 
BCWP (Budgeted Cost of Work Performed) 
LA (Layout Appropriateness) 

CRC (Class-Responsibility-Collaborator) 
ACWP (Actual Cost of Work Performed) 
ATC (Air Traffic Control) 

COTS (Commercial Off-The-Shelf) 

CBD (Component-Based Development) 

CD (Controlled Decentralised) 

KDD (Knowledge Discovery in Databases) 
SCD (System Context Diagram) 

DD (Democratic Decentralized) 

IDS (Intentional Deviation from Specification) 
ERD (Entity Relationship Diagram) 

FD (Formal Design) 
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Término en Español 


DFC (Desplieguede la función de calidad) 

DFC (Diagrama de flujo de control) 

DFD (Diagrama de flujo de datos) 

DFS (Diagramade flujo del sistema) 

DIT (Documentaciónimprecisa o incompleta) 

DOO (Diseño orientado a objetos) 

DPR (Diseño para la reutilización) 

DRA (Desarrollorápido de aplicaciones) 

DSED (Desarrollode sistemas estructurados de datos) 

DSJ (Desarrollo de sistemas Jackson) 

DSN (Diseño de sistema de negocio) 

DTE (Diagramade transición de estados) 

EAIP (Entorno de apoyo integrado a proyectos) 

EAT (Estructuras de análisis del trabajo) 

EC (Especificación de control) 

ECS (Elementos de configuracióndel software) 

ED (Elementos de datos) 

EDC (Espacio de diseño cuantificado) 

EDE (Elementos de datos de entrada) 

EDR (Elementos de datos retenidos) 

EDS (Elementos de datos de salida) 

EEC (Especificaciónde estructura de cajas) 

EED (Eficacia de eliminación de defectos) 

EIE (Especificación incompleta o errónea) 

EIS (Entorno de ingeniería del software) 

ELD (Erroren la lógica de diseño) 

EP (Especificación de proceso) 

ERD (Error en representación de datos) 

ES (Estados) 

ETRP (Evaluacióny técnica de revisión de programas) 

FA (Factorde acoplamiento) 

FHA (Factor de herencia de atributo) 

FHM (Factorde herencia de métodos) 

FIR (FICA .impuesto.retenido) 

FP (Factorde polimorfismo) 

FPGC (Facilidades de presentación gráfica de computadora) 

FURPS (Funcionalidad, facilidad de uso, fiabilidad, 
rendimiento y capacidad de soporte) 

FZ (Fijarzona) 

GBD (Gestión de base de datos) 

GC (Generaciónde código) 

GCS (Garantía de calidad del software) 

GCS (Gestión de la configuración del software) 

GIP (Grupo independientede prueba) 

OCM/OPM (Objetivo, cuestión (pregunta), métrica) 

GTC (Gestión total de calidad) 

HD (Habilitar/deshabilitar) 

HIR (Hoja de información del riesgo) 

HTTP (Protocolo de transferenciade hipertexto) 

IA (Inteligenciaartificial) 

IC (Inspecciónde código) 

1-CASE (CASE integrado) 

ICED (Índice de calidad de la estructura de diseño) 

ICMP (Protocolo de mensajes de control de Internet) 

IDC (Índice de desarrollo de coste) 

IDL (Lenguaje de definición de interfaces) 

IDP (Índice de desarrollo de planificación) 

IE (índice de error) 

TEC (Informes de estado de la configuración) 

TEP (Incumplimientode los estádandares de programación) 

IES (índice de especialización) 

IF (Índice de fase) 

IGU (Interfaz gráfica de usuario) 

IHM (Interfaz hombre-máquina) 

IMI (Interfaz de módulo inconsistente) 

IMS (índice de madurez del software) 


Término equivalente en Inglés 


QFD (Quality Function Deployment) 

CFD (Control Flow Diagram) 

DFD (Data Flow Diagram) 

SFD (System Flow Diagram) 

TD (Inaccurate or Incomplete Documentation) 

OOD (Object-Oriented Design) 

DFR (Design forReuse) 

RAD (Rapid Application Development) 

DSSD (Data Structured Systems Development) 

JSD (Jackson System Development) 

BSD (Business System Design) 

STD (State Transition Diagram) 

IPSE (Integrated Project Support Environment) 

WBS (Work Breakdown Structure) 

CSPEC (Control Specification) 

SCI (Software Configurationltems) 

DE (Data Elements) 

QDS (Quantity Design Space) 

DEI (Input Data Elements) 

DER (Retained Data Elements) 

DEO (Output Input Data Elements) 

BSS (Box Structure Specification) 

DRE (DefectRemoval Efficiency) 

IES (Incompleteor Erroneous Specification) 

SEE (Software Engineering Environment) 

EDL (Errorin Design Logic) 

PSPEC (Process Specification) 

EDR (Error in Data Representation) 

ST (States) 

PERT (Program Evaluation and Review Technique) 

CF (Coupling Factor) 

AIF (Attribute Inheritance Factor) 

MIF (Method Inheritance Factor) 

FTW (FICA. Tax. Withheld) 

PF (Polymorphism Factor) 

CGDF (Computer Graphics Display Facilities) 

FURPS (Functionality,Usability, Reliability, 
Performance and Supportability) 

ZS (Zone Set) 

DBM (Database Management) 

CG (Code Generation) 

SQA (Software Quality Assurance) 

SCM (Software Configuration Management) 

ITG (IndependentTest Group) 

GQM (Goal, Question, Metric) 

TOQM (Total Quality Management) 

AD (Arm-Disarm)(p. 731) 

RIS (Risk Information Sheet) 

HTTP (Hypertext Transfer Protocol) 

Al (Artificial Intelligence) 

CI (Code Inspection) 

I-CASE (IntegratedCASE) 

DSQI Design Structure Quality Index) 

ICMP (Intemet Control Message Protocol) 

CPI (Cost Performance Index) 

IDL (Interface Definition Language) 

SPI (Schedule Performance Index) 

El (Error Index) 

CSR (Configuration Status Reporting) 

VPS (Violation of Programming Standards) 

SI (Specialisation Index) 

PI (Phase Index) 

GUI (Graphical User Interface) 

HCI (Human-ComputerInterface) 

ICT (InconsistentComponent Interface) 

SMI (Software Maturity Index) 
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IP (Protocolo de Intemet) 

IPN (Ingeniería de proceso de negocio) 

IS (Ingeniería de sistemas) 

ISBC (Ingeniería del software basada en componentes) 

ISOO (Ingeniería del software orientada a objetos) 

ISOOAC (Ingeniería del software orientada a objetos asistida 
por computadora) 

IU (Interfaz de usuario) 

TIUSC (Interfaz de usuario y funciones de control) 

IWeb (Ingeniería Web) 

KLDC (mil líneas de código) 

LDAs (Lenguajes de descripción arquitectónica) 

LDC (Líneas de código) 

LDP (Lenguaje de diseño de programas) 

LIM (Lenguaje de interconexión de módulos) 

LPNI (Límite de proceso natural inferior) 

LSPN (Límite superior del proceso natural) 

MACA (Método de análisis de compromiso para la arquitectura) 

MAD (Módulos de análisis de diseño) 

MCC (Mala interpretación de la comunicación del cliente) 

MCC (Método del camino crítico) 

MCM (Modelo de capacidad de madurez) 

MCP (Marco común de proceso) 

MDOO (Métricas para el diseño orientado a objetos) 

MEPS (Mejora estadística del proceso de software) 

MMCGP (Modelo de madurez de la capacidad de gestión de persona]) 

MMGR (Mitigación, monitonzación y gestión del riesgo) 

Modelo MOI (Motivación, organización, ideas o innovación) 

MOM (Software intermedio orientado a mensajes) 

MPC (Métodos ponderados por clase) 

NCC (Número de clases clave) 

NCR (Número de clases raíz) 

NDD (Número de descendientes) 

NE (Número de escenarios) 

NN (Nodos de navegación) 

NOA (Número de operaciones añadidas por una subclase) 

NOR (Número de operaciones redefinidas para una subclase) 

NPD (Número de padres directos) 

NP rom (Número de parámetros por operación promedio) 

NSUB (Número de subsistemas) 

OB (Objetos) 

OCI (Orden de cambio de ingeniería) 

OCV (Objetivos del ciclo de vida) 

ODBC (Conectividad abierta de bases de datos) 

OLCRS (Sistema interactivo para apuntarse a cursos) 

OMG/CORBA (Grupo de gestión de objetos/Arquitectura común 
de distribución de objetos) 

00 (Orientado a objetos) 

ORB (Agente de distribuición de objetos) 

P (Prueba) 

PE€R (Pregunta y respuesta) 

PAT (Presupuesto a la terminación) 

PEI (Planificación de la estrategia de información) 

PEN (Proceso elemental de negocios) 

PF (Puntos de función) 

Pfu (Primitivas funcionales) 

PIE (Prueba incompleta o errónea) 

PMFu (Primitivas modificadas de función manual) 

POO (Programación orientada a objetos) 

POP3 (Protocolo de oficina de correos versión 3) 

PP. (Planificación de prueba) 

PPP (Porcentaje público y protegido) 

PRO/SIM (Construcción de prototipos y simulación) 

PrOO (Pruebas orientadas a objetos) 

PSI (Procesos secuenciales intercomunicados) 

RE (Relaciones) 
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IP (Internet Protocol) 

BPE (Business Process Engineenng) 

SE (System Engineering) 

CBSE (Component-Based Software Engineering) 

OOSE (Object-Oriented Software Engineering) 

OOCASE (Object-Oriented Computer Aided Software 
Engineering) 

UL (User Interface) 

UICE (User Interface and Control Facilities) 

WebE (Web-Engineering) 

KLOC (thousands lines of code) 

ADLs (Architectural Description Languages) 

LOC (Lines of Code) 

PDL (Program Design Language) 

MIL (Module Interconnection Language) 

LPNL (Lower Natural Process Limit) 

UNPL (Upper Natural Process Limit) 

ATAM (Architecture Trade-off Analysis Method) 

DAM (Design Analysis Modules) 

MCC (Misinterpretation of Customer Communication) 

CPM (Critical Path Method) 

CMM (Capability Maturity Model) 

CPF (Common Process Framework) 

MOOD (Metrics for Object-Onented Design) 

SSPI (Statistical Software Process Improvement) 

PM-CMM (People Management Capability Maturity Model) 

RMMM (Risk Mitigation, Monitoring and Management) 

MOI Model (Motivation, Organisation, Ideas or innovation) 

MOM (Message Oriented Middleware) 

WMC (Weighted Methods per Class) 

NKC (Number of Key Classes) 

NOR (Number of Root Classes) 

NOC (Number of Children) 

NSS (Number of Scenario Scripts) 

WoN (Ways of Navigating) 

NOA (Number of Operations Added by a subclass) 

NOO (Number of Operations Ovemdden by subclass) 

FIN (Fanin) 

NP aYE (Average Number of Parameters per operation) 

NSUB (Number of Subsystems) 

OB (Objects) 

ECO (Engineering Change Order) 

LCO (Life Cycle Objectives) 

ODBC (Open Database Connectivity) 

OLCRS (On-Line Course Registration System) 

OMG/CORBA (Object Management Group/Common Object 
Request Broker Architecture) 

00 (Object-Oriented) 

ORB (Object Request Broker) 

T (test) 

QA (Question and Answer) 

BAC (Budget At Completion) 

ISP (Information Strategy Planning) 

EBP (Elementary Business Process) 

FP (Function Points) y 

FuP (Functional Primitives) 

TET (Incomplete or Erroneous Testing) 

FuPM (Modified Manual Function Primitives) 

OOP (Object-Oriented Programming) 

POP3 (Post Office Protocol version 3) 

TP (Test Planning) 

PAP (Percent Public and Protected) 

PRO/SIM (PROtotyping and SIMulation) 

OOT (Object-Oriented Testing) 

CSP (Communicating Sequential Processes) 

RE (Relationships) 
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Re, (Conexiones de relación) 

RFP 

Rm (Rangos de movimiento) 

RPC (Respuesta para una clase) 

RPN (Reingeniería de procesos de negocios) 

RR (Recolección de requisitos) 

RTF (Revisión técnica formal) 

SBDOO (Sistemas de bases de datos orientadas a objetos) 
SCCT (Sistema de clasificación de cinta transportadora) 
SCE (Salidas/Control/entradas) 

SDIU (Sistemas de desarrollo de la interfaz de usuario) 
SEI (Instituto de ingeniería de software) 


SGBDOO (Sistemas de gestión de bases de datos orientadas a objetos) 


SGBDR (Sistema de gestión de bases de datos relacional) 
SGH (Servicios de gestión de herramientas) 

SIG (Sistemas de información de gestión) 

SQA (Gestión de calidad de Software) 

SQE (Ingeniería de Calidad del software) 

SQL (Lenguaje de consultas estructurado) 

SSRB (Sistema de seguimiento y reparación de baches) 
T4G (Técnicas de cuarta generación) 

TADE (Técnicas de Análisis y diseño estructurado) 
TAP (Tabla de activación de procesos) 

TC (Tamaño de clase) 

TC; (Muestras (tokens) de datos) 


TFEA (Técnicas para facilitar las especificaciones de la aplicación) 


TI (Tecnologías de la información) 


TLP (Error en la traducción del diseño al lenguaje de programación) 


TMC (Tiempo medio de cambio) 
TMEF (Tiempo medio entre fallos) 
TMEF (Tiempo medio entre fallos) 
TMO (Técnica de modelado de objetos) 
TMR (Tiempos medios de reparación) 
TObrom (Tamaño medio de operación) 
TR (Transiciones) 

UML (Lenguaje de modelado unificado) 
USN (Unidad semántica de navegación) 
Ve V (Verificación y validación) 

VC (Varianza del Coste) 

VC (Verificación de corrección) 

VP (Varianza de planificación) 
WebApps (Aplicaciones basadas en Web) 
XML (Lenguaje de marcas extensible) 


Siglas Inglés / Espanol 
Término en Inglés 


2DGA (Two-dimensional Geometnc Analysis) 
3DGA (Three-dimensional Geometric Analysis) 
4GT (Fourth Generation Techniques) 

ACWP (Actual Cost of Work Performed) 

AD (Arm-Disarm) 

ADLs (Architectural Description Languages) 
Al (Artificial Intelligence) 

AIF (Attribute Inbentance Factor) 

API (Application Programming Interface) 
ATAM (Architecture Trade-off Analysis Metbod) 
ATC (Air Traffic Control) 

BAA (Business Area Analysis) 

BAC (Budget At Completion) 

BCWP (Budgeted Cost of Work Performed) 
BCWS (Budgeted Cost of Work Scheduled) 
BDK (Bean Development Kit) 
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Re, (Relationship connections) 

RFP 

mR (moving range) 

RFC (Response for a class) 

BPR (Business Process Reengineering) 

RG (Requirements Gathering) 

FTR (Formal Technical Review) 

OODBS (Object-Oriented Database System) 
CLSS (Conveyor Line Sorting System) 

OCI (Output/Control/Input) 

UIDS (User-Interface Development Systems) 
SEI (Software Engineering Institute) 


OODBMS (Object-Oriented Database Management System) 


RDBMS (Relational Database Management System) 
TMS (Tools management services) 

MIS (Management Information System) 

SQA (Software Quality Assurance 

SQE (Software Quality Engineenng) 

SQL (Structure Query Language) 

PHTRS (Pot Hole Tracking and Repair System) 
4GT (Fourth Generation Techniques) 

SADT (Structured Analysis and Design Technique) 
PAT (Process Activation Language) 

CS (Class Size) 

TC, (Data tokens) 

FAST (Facilitated Application Specification Techniques) 
IT (Information technologies) 

PLT (error in Programming Language Translation) 
MTTC (Mean-time-to-change) 

MTTF (Mean time to failure) 

MTBF (Mean time between failure) 

OMT (Object Modelling Technique) 

MTTR (Mean time to repair) 

OS,,, (Average Operation Size) 

TR (Transitions) 

UML (Unified Modelling Language) 

SNU (Semantic Navigation Unit) 

Ve€V (Verification and Validation) 

CV (Cost Variance) 

CV (Correctness Verification) 

SV (Schedule Variance) 

WebApps (Web-based Applications) 

XML (Extensible Mark-up Language) 
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AG2D (Análisis geométrico de dos dimensiones) 
AG3D (Análisis geométrico de tres dimensiones) 
T4G (Técnicas de cuarta generación) 

CRTR (Coste real de trabajo realizado) 

HD (Habilitar/deshabilitar) 

LDAs (Lenguajes de descripción arquitectónica) 
IA (Inteligencia artificial) 

FHA (Factor de herencia de atributo) 

API (Interfaz de programación de aplicaciones) 


MACA (Método de análisis de compromiso para la arquitectura) 


CTA (Control de tráfico aéreo) 

AAN (Análisis del área del negocio) 

PAT (Presupuesto a la terminación) 

CPTD (Coste de presupuestos del trabajo desarrollado) 
CPTP (Coste presupuestado del trabajo planificado) 
BDK (Kit de desarrollo Bean) 
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BPE (Business Process Engineering) 

BPR (Business Process Reengineering) 

BRO (Branch and Relational operator) 

BSD (Business System Design) 

BSS (Box Structure Specification) 

BVA (Boundary Value Analysis) 

C (Certification) 

C£I (Construction and Integration) 

C/S (Client/Server) 

CAD (Computer-Aided Design) 

CASE (Computer-Aided Software Engineenng) 
CBD (Component-Based Development) 

CBO (Coupling Between Object Classes) 
CBSE (Component-Based Software Engineering) 
CC (Controlled Centralised) 

CCA (ChangeControl Authority) 

CD (Controlled Decentralised) 

CF (Coupling Factor) 

CFD (ControlFiow Diagram) 

CG (Code Generation) 

CGDF (Computer Graphics Display Facilities) 
CGI (Common Gateway Interface) 

CI (Code Inspection) 


CK metrics suite (Chidamber and Kemerer metrics) 


CLSS (Conveyor Line Sorting System) 
CMM (Capability Maturity Model) 
COCOMO (Constructive Cost Model) 
COM (Component Object Model) 


CORBA (Common Object Request Broker Architecture) 


COTS (Commercial Off-The-Shelf) 
CPF (Common Process Framework) 
CPI (Cost Performance Index) 

CPM (Critical Path Method) 

CRC (Class-Responsibility-Collaborator) 
CS (Class Size) 

CSP (Communicating Sequential Processes) 
CSPEC (Contrpl Specification) 

CSR (Configuration Status Reporting) 
CV (Correctness Verification) 

CV (CostVariance) 

DAM (Design Analysis Modules) 
DBM (Database Management) 

DD (Democratic Decentralized) 

DE (Data Elements) 

DET (Input Data Elements) 

DEO (Output Data Elements) 

DER (Retained Data Elements) 

DFD (DataFlow Diagram) 

DFR (Design For Reuse) 

DIT (Depth of the Inheritance Tree) 
DRE (Defect Removal Efficiency) 
DSQI (Design Structure Quality Index) 
DSSD (Data Structured Systems Development) 
DU chain (Definition-Use chain) 

EBP (Elernentary Business Process) 
ECO (Engineering Change Order) 
EDL (Errorin Design Logic) 

EDR (Errorin Data Representation) 

El (ErrorIndex) 

ERD (Entity Relationship Diagram) 
EVA (Earned Value Analysis) 


FAST (Facilitated Application Specification Techniques) 


FD (Formal Design) 

FIN (Fanin) 

FP (Function Points) 

FTR (Formal Technical Review) 
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IPN (Ingenieríade proceso de negocio) 

RPN (Reingenieríade procesos de negocios) 

BRO (Operadorrelacional y de ramificación) 

DSN (Diseñodesistema de negocio) 

EEC (Especificación de estructura de cajas) 

AVL (Análisisde valores límites) 

C (Certificación) 

CRI (construcción e integración) 

C/S (Cliente/servidor) 

CAD (Diseño asistido por computadora) 

CASE (Ingenieríadel software asistida por computadora) 
DBC (Desarrollobasado en componentes) 

ACO (Acoplamiento entre clases de objetos) 

ISBC (Ingenieríadel software basada en componentes) 
CC (Centralizadocontrolado) 

ACC (Autoridad de control de cambios) 

DC (Descentralizadocontrolado) 

FA (Factor de acoplamiento) 

DFC (Diagrama de flujo de control) 

GC (Generación de código) 

FPGC (Facilidadesde presentación gráfica de computadora) 
CGI (Interfazcomún de pasarela) 

IC (Inspección de código) 

CK serie de métricas (Chidamber y Kemerer) 

SCCT (Sistema de clasificación de cinta transportadora) 
MCM (Modelo de capacidad de madurez) 
COCOMO (Modelo constructivodel coste) 

COM (Modelo de objetos para componentes) 
CORBA (Arquitecturacomún de distribución de objetos) 
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